• Errors from make like /c:not found: make sure you set the environment variable MAKE_MODE to UNIX in your .bashrc, Emacs init file, or Control Panel [NT]/AUTOEXEC.BAT [95]
• Lots of compile errors, esp. on lines containing macro definitions terminated by backslashes: Your partition holding the source files is mounted binary.  needs to be text.  [this will not screw up any binary files because the Cygwin utilities specify explicitly whether they want binary or text mode when working with source vs. binary files, which overrides the mount type.]
• Problems with build not working -- e.g. make failing with exit code 127 in inexplicable situations, syntax errors running configure scripts -- you have ash in /bin/sh; you need bash there.

what is the sequence of events when a layout is created?  how does redisplay updating of a layout work?

• how do I turn off backups, or put them all in one place?
• My auto-save is slow!
• how do I put all auto-save files in one place?
• how do I search over multiple files?
• how do I do a search and replace over multiple files?
• when using regular expressions to do a search/replace, how do I remember part of what was found and insert it a the appropriate place in the replace string?
• how do I enable or disable use of the alt key under windows as a menu accelerator, as opposed to as the meta key for M-f and such?
• how do I use gnuclient under windows?
• where is a list of all XEmacs versions and release dates?

Fix up automatic adding of menu accelerators to be always unique.  Use the following algorithm:

1. scan the current submenu and extract the accelerators into some sort of hash table, perhaps one that's always around to avoid excessive consing.
2. check for duplicates; if so, resolve them by a possibly user-specifiable algorithm, whose default [and simplest] implementation is, for each set of duplicates, to allow the first duplicate to get the accelerator, and for each of the others, in turn, to have the first letter in their name that's not already assigned to an accelerator become that item's accelerator.  If there are no such letters, a character is prepended to the menu item string and becomes that item's accelerator.  The character is determined by scanning through the numbers 1 through 9, then 0, then a through z, looking for the first one not already taken as an accelerator.  If we run out of such characters, we just give up and let the item have its own accelerator.
3. After handling items with explicitly specified accelerators, we handle the rest, using essentially the same algorithm as in the previous step.

Options to control the above process:

• There should be a command that lets you check for duplicates among a submenu and suggest non-duplicative accelerators according to the above scheme.  That would make it much easier for someone who's manually adding accelerators: They could take the output and just tweak it a bit as they see fit, and voila they have nice accelerators.
• Eventually, maybe, there should be other algorithms.  The algorithm above is essentially a "first-fit" type of algorithm; I could easily imagine a best-fit algorithm, which tried, e.g. to minimize the sum over all menu items processed of the number of letters between the accelerator and the first letter in the menu item, and/or tried to minimize the number of situations where no letter in the menu item is available and it's necessary to fall back on auto-generated numbers/letters.
• The last phase, where auto-generated numbers and letters are added, should perhaps be controllable -- i.e. you specify under what circumstances it happens at all.  For example, Windows is smart enough in accelerator-shadowing situations to allow you to hit the accelerator more than once to access accelerator-shadowed menu items, even when the shadowing item is a submenu [even in the menu bar] -- in that case, the submenu does not automatically open, and you can either hit the accelerator key again to get successively shadowed items, or move around the submenu or menu bar with the arrow keys, or open the submenu with the down arrow [menu bars] or right arrow [submenus].  It's possible that the X support isn't quite so smart and doesn't handle the menu bar shadowing so well.  So we might want a flag, possibly even a specifier, to control whether this last phase happens. [#### And we should fix the X accelerator support, to boot!]

Michael, I just noticed something -- create-compatibility-dot-emacs always sets the init-file and custom-file to the .el versions, not the .elc ones even if they exist. Is this intentional?

 I also think that the code that looks for init.elc and init.el should check to make sure the .elc file is up-to-date. If not, it should load the .el file instead and issue a prominent warning about the situation. Otherwise, many people will doubtlessly get bitten by changing their .el file, forgetting to recompile, and wondering why nothing is happening!

 Same would go for custom.el except that presumably custom.elc is ignored, right? [If so, and if custom.elc is present, a warning should be issued about this.]

 Finally, if you have compiled init.el, user-init-file will currently be set to ~/.xemacs/init.elc. I think this is a definite mistake -- lots of code will undoubtedly assume that it can edit user-init-file, not realizing that the `c' has to be chopped off.

e.g. the current code in menubar-items:

       ["Edit I%_nit File"
       ;; #### there should be something that holds the name that the init
       ;; file should be created as, when it's not present.
       (progn (find-file (or user-init-file "~/.xemacs/init.el"))
              (or (eq major-mode 'emacs-lisp-mode)
                  (emacs-lisp-mode)))]

• Edit -> Fill -> Fill Paragraph or Region,
• Fill and Full-Justify Paragraph or Region
• Fill and Justify Paragraph or Region As Set
• Set Justification for Paragraph or Region -> Left
• Right
• Full
• Center
• None

i just read the docs, and the above behavior is exactly as documented. the bug is in our code, which apparently has never worked right.  the solution:

• drain_X_queue[] has a bug in it. it should read

    while (XEventsQueued (display, QueuedAfterReading))
      XtAppProcessEvent (Xt_app_con, XtIMXEvent);
  

  NOT:

    while (XtAppPending (Xt_app_con) & XtIMXEvent)
      XtAppProcessEvent (Xt_app_con, XtIMXEvent);
  

  this also alleviates the problem mentioned in

    /* XtAppPending() can be super-slow, esp. over a network connection. ... */
  

•  change x_check_for_quit_char:

        x_check_for_quit_char (Display *display)
        {
          drain_X_queue();
          scan_dispatch_queue_for_a_C_g_event_setting_Vquit_flag_if_appropriate();
        }
  

  where the latter function does as named, and can be closely modelled on emacs_mswindows_quit_p(). (WARNING, its handling of critical-quit i.e. C-S-g is broken. make sure your version works.)

byte-compilation warnings should have a line number by them so that next-error and previous-error can be set up to work properly. (There is a line number there now, but it is not very accurate.) At least two improvements could be made:

1. unresolved functions are not reported till the end of the file, but the line number where the function was first encountered (or perhaps, all the line numbers) should be stored along with the function name, to be output later.
2. the compiler reads a whole defun at a time, so currently our line numbers end up being always at the end of the defun. to fix this, probably the best way is to provide a new interface to `read' and friends that takes a hash-table on input and stores in it pointers to conses, vectors, and strings as keys and the corresponding buffer character position as values. even better, for conses and vectors, the value should contain a cons of the buffer position of the start of the sequence and another cons or vector (as appropriate), each of whose elements contains a buffer position indicating the position of the start of the appropriate element in the cons or vector being referred to. that way, the position of symbols, numbers, and other non-unique Lisp objects can be found as well.

fix lazy-lock so that if you open a new file, go to the bottom, and hold down page-up, you actually see screens go by instead of just freezing. the problem here has to do with limitations of the input preemption mechanism. it goes like this:

1. user holds down page-up. first page-up received.
2. normally, redisplay is fast, faster than the delay between repeated keys.
3. but with lazy-lock enabled, it will be called first from pre-idle-hook.
4. the call to lazy-lock goes through because no more page-ups have been received yet.
5. lazy-lock fontifies the page, which takes so long that one or more repeated keys are received.
6. redisplay sees the received keys and preempts itself.
7. the received keys are rapidly handled, paging up but preempting both lazy-lock and redisplay.
8. when the last buffered key is processed, the cycle starts again:
9. lazy-lock is called, takes its time fontifying, and redisplay is preempted again.

one solution would be to internally track keys going up and down in the event code, and provide some external access to this. if a non-modifier key is down, we can use this to pre-empt lazy lock but not redisplay. we then just have to make sure that pre-idle hook is called when the last non-modifier key goes up, or perhaps after a certain amount of time of no activity (e.g. 1/8 of a second, well more than the repeat delay) so that the user doesn't see totally weird results if they're holding a key down that isn't doing anything, or if something gets messed up in the internal keyboard state and a key gets reported down that isn't really.

include-if Lisp-Expr

ignore dir completely if Lisp-Expr is false. when ignored:

• not on load path
• no autoloads or custom loads

include-file-if file Lisp-Expr

applies to one file. when ignored:

• no autoloads or custom loads for file
• not byte-compiled
• ignored by XEmacs packages that recognize the package-info file

if-supported Command
...
endif

do stuff in between only if Command is recognized in this file format.

but maybe that whole scheme is way ad-hoc and really stretching the whole concept of keymaps.  instead maybe we just want to keep the existing scheme, and conceivably allow for extent and glyph properties specifying mouse-track hooks, which are handled preferentially to the global or buffer-local properties.  i think hrvoje's main complaint was just about not knowing what hooks are actually run. [for that matter, will describe-key correctly pick up any extent-local, glyph-local, etc. keymaps if you click on one of them??] the way to fix that would be [1] make sure that describe-key does correctly pick up these extent-local etc. keymaps; [2] for mouse-track in particular, have describe-key list the values of the hooks applicable to where the mouse was clicked.  the easiest and cleanest way to do this would be to have some sort of property on the `mouse-track' symbol, maybe `describe-key-documentation', that is a function that allows mouse-track to specify dynamic documentation.  whenever describe-key comes across such a special function, it calls it, with the buffer to put the data into in `standard-output' and the function's actual doc string.  there should be an obvious function [if there's not already] which outputs exactly what describe-key normally outputs, and in addition the function can describe the relevant hooks or do whatever the hell it wants. 

• only needs to recompute from beginning of changed segment, as far as end change, maybe farther
• when new-computed syntax matches old one, we can almost always stop. [#### when not?] seems if we find a whole line that matches, we can always stop.  perhaps "always" if we maintain a bit of additional state on the extent about what chars caused the state?
• in case of double quote, we might end up recomputing to the end [not in C but in Lisp]; /* in C might also cause excessive recomputing.  so only go to window end and a ways past it [some heuristic], then remember that the rest may be inaccurate.  then, eventually when closing match is inserted, everything be noticed as accurate. [this requires dealing with the possibility of window movement -- needs a lazy-lock type driving program]

verify that make install works from both the top level and a subdir such as oa/edit-utils.  send first file change to steve y, check in the second.