--- Luc Teirlinck <[EMAIL PROTECTED]> wrote: > Both Stefan and me might have partially misunderstood your problem. >
That's okay, I've only understood about 2% of this whole thread. :) > `sql-interactive-mode' calls comint-mode without enclosing it in a > delay-mode-hooks form, as it should. To standardize your mode, you > should either define it using `define-derived-mode' (see > `(elisp)Derived > Modes') or read `(elisp)Mode Hooks'. > I've added the `delay-mode-hooks' to the code, so this should be correct going forward. I inherited this mode so I'm still grasping some of it's inner workings. In fact, it hasn't been `sql-interactive-mode' that has had the font-lock problems. The font-lock setup needed in sql-interactive-mode is known when the mode starts, so it can be setup during initialization of the mode. I also verified that sql-interactive-mode does not enable font-lock-mode. It may flip it off and on (after killing font-lock-set-defaults, to get it to reinitialize), iff it is already turned on. The other mode in sql.el is `sql-mode' which is designed to provide editting support of sql scripts is where font-lock has been a challenge. This is not a derived mode so that is not the cause. The need here is to change the keyword rules based upon a local variable section setting or a menu selection. I can easily recalculate the font-lock-defaults needed, the problem was getting font-lock to refresh its internal configuration based on new font-lock-defaults settings. My suggestion to use `font-lock-defontify' was the result of several late nite debugging sessions about six months ago. It seems to no longer be necessary. Stefan's suggestion to kill `font-lock-set-keywords' was already in place but it didn't seem to have a visual impact unless I called `font-lock-defontify'. > The reason why you need `font-lock-defontify' is because I believe (I > did not check this in detail) that all comint uses font-lock for is > font-lock-face, which is exactly what `font-lock-defontify' undoes. > My patches do not try to mend this because most comint derived modes > probably _want_ to keep comint's font-lock-face defaults. > > After standardizing your mode, you _maybe_ might still have to run > font-lock-defontify to remove comint's font-lock-face properties. > (I did not study your code in detail, nor am I completely sure about > what your exact problem is.) > I think sql.el is now properly behaving in terms of its responsibilities relative to derived and minor modes. I'll continue to test it until changes in this area settle down. I will release the patch once I am comfortable that things are stable again... _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
