[Top][All Lists]
[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...
- Re: org-mode and mode hooks., (continued)
- Re: org-mode and mode hooks., Luc Teirlinck, 2005/05/27
- Re: org-mode and mode hooks., Michael Mauger, 2005/05/27
- Re: org-mode and mode hooks., Luc Teirlinck, 2005/05/27
- Re: org-mode and mode hooks., Luc Teirlinck, 2005/05/27
- Re: org-mode and mode hooks., Stefan Monnier, 2005/05/27
- Re: org-mode and mode hooks., Luc Teirlinck, 2005/05/27
- Re: org-mode and mode hooks.,
Michael Mauger <=
- Re: org-mode and mode hooks., Luc Teirlinck, 2005/05/27
- Re: org-mode and mode hooks., Richard Stallman, 2005/05/28
- Re: org-mode and mode hooks., Luc Teirlinck, 2005/05/28
- Re: org-mode and mode hooks., Richard Stallman, 2005/05/26
- Re: org-mode and mode hooks., Luc Teirlinck, 2005/05/26
- Re: org-mode and mode hooks., Luc Teirlinck, 2005/05/26
- Re: org-mode and mode hooks., Lute Kamstra, 2005/05/25
Message not available
Re: org-mode and mode hooks., Richard Stallman, 2005/05/26