emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: org-mode and mode hooks.


From: Michael Mauger
Subject: Re: org-mode and mode hooks.
Date: Tue, 31 May 2005 11:25:59 -0700 (PDT)

--- Luc Teirlinck <address@hidden> 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...




reply via email to

[Prev in Thread] Current Thread [Next in Thread]