> HAVE_MENUS means menu support on the C level. tmm doesn't do that, it > _emulates_ menus on the Lisp level.
OK. I see now. > > However, xmenu.c _does_ compile without > > X11 headers and libraries, otherwise you couldn't make a non-X build with > > it. > > If the headers and libraries are present on the system, you could > build such a version allright. xmenu.c compiles without X libraries (--without-x doesn't link to them) but now I think that the non-X build on Unix and GNU systems doesn't define HAVE_MENUS because it shouldn't need xmenu.c > > > Meanwhile, I don't think we should apply your suggested changes, since > > > compiling xmenu.c on a system without X headers and libraries might > > > fail due to unresolved externals. > > > > It solved the OP's problem. I suggest that we do apply it as thats the > > only way to test it. If it is wrong, I am sure we will hear about it > > shortly. > > No need, as I fixed that differently. Yes, I think your change is generally right, non-X builds don't seem to use menu-updating-frame (it's always nil if defined). However you have missed some references to menu-updating-frame. For example F10->f doesn't work beacuse of: (put 'dired 'menu-enable '(not (window-minibuffer-p (frame-selected-window menu-updating-frame)))) You might also need display-multi-frame-p in kill-this-buffer-enabled-p. Nick _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel