Stephen J. Turnbull writes: It occurs to me that the maintenance burden can be reduced, with an increase in overall convenience and reliability, by folding this into the menubar code itself. The idea is to make the above tests part of the menubar infrastructure, rather than the menubar spec. So the algorithm would go something like (1) process a command item spec as currently done (2) if no :included keyword was present, check for commandp of the specified "command". if this test succeeds, add the item to the menu being built otherwise, if menu-developer-p is non-nil, log a warning, and do not add the item to the menu (3) if no :active keyword was present, check whether any of the active modes provided the command if this test succeeds, activate the command in the menu otherwise, if menu-developer-p is non-nil, log a warning, and deactivate the item `menu-developer-p' is a new defcustom which would default to t in betas, and nil in the stable code. The test in (3) probably requires additional infrastructure. I'm not sure if the algorithm is right, either, but you can see where this is going, I hope. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta