Stefan Monnier wrote: Actually, don't worry too mucvh about that, because I think that even with the current code things don't work right unless the major mode follows the conventions w.r.t major-mode-derivation.
My changes do not introduce new problems, they fix problems with the current code. The problem is that the fix is not perfect. It limits the situations in which problems occur and makes the consequences less severe if they occur. With the current code problems are _much_ more likely to happen than with my proposed changes. For instance with the current code, enabling Font Lock mode in a major mode body, like for instance sql-interactive-mode does, will cause problems for derived modes, no matter how well the major mode conventions are followed. The fact that sql-interactive-mode later disables Font Lock again does not correct this. Also the consequences are much more severe with the current code. With the current code, Font Lock may get set up for the wrong major mode, giving completely incorrect fontification. After my changes, there is the slight probability of loosing a few keywords for major modes that do not follow the conventions. I believe that it is possible to implement things completely reliably by letting major modes specify a list of major modes from which they want to inherit keywords and using a non-nil MODE argument. But that would require more extensive changes to Font Lock and would also require some (much less extensive) changes to define-derived-mode. I believe that a nil argument for MODE has been around for a while so for backward compatibility, one would still need to reasonably take care of such calls. The question is whether the remaining problems are worth the trouble. Sincerely, Luc. _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
