emacs-devel
[Top][All Lists]
Advanced

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

Re: problem with mh-e and 2002-08-20 change to font-core.el


From: Stefan Monnier
Subject: Re: problem with mh-e and 2002-08-20 change to font-core.el
Date: Thu, 29 Aug 2002 11:25:42 -0400

>     > That would not do the job; it would fail to remove all the properties
>     > which the current code removes.
> 
>     Can you give examples ?
> 
> Modes that use font-lock-face are an example.  The current code
> removes that property; just turning off font-lock-mode would not
> remove it.
> 
> font-lock-face properties go in mode-specific places.

But do the properties belong to the text or to the mode.
I have the impression that most of those font-lock-face properties
are added together with the corresponding text and that they can't
be recovered just from the text.  I.e. erasing them might not
be the right thing to do since it loses information.

>     PS: And the current code fails to remove those properties if you didn't
>       turn font-lock-mode ON, which doesn't make much sense either.
> 
> Sorry, I don't understand.  Would you say that more clearly?

The "erase the font-lock-face property when changing-mode" hook you
added is only added when you turn on font-lock-mode, so the
font-lock-face property will stay if you don't turn on font-lock-mode
before changing major-mode.

Examples:

        emacs -q --no-site-file
        M-x ibuffer
        M-x text-mode
        M-: (ibuffer-mode)
        M-x font-lock-mode

you see the font-locked text.  Now try this instead:

        emacs -q --no-site-file
        M-x ibuffer
        M-x font-lock-mode
        M-x text-mode
        M-: (ibuffer-mode)
        M-x font-lock-mode

now you don't see any fontification.
I actually think that the first behavior is more correct and
corresponds to what happens if you call (font-lock-mode -1) instead
of forcefully erasing the font-lock-face property.


        Stefan

PS: The elisp manual clearly says in the "major mode conventions"
node to "Define a command whose name ends in `-mode'" so ibuffer-mode
should be interactive.  I'd of course argue that it should use
`define-derived-mode' which would have made it interactive as a matter
of course without the programmer having to think about it.
As long as we don't use such a macro systematically, we'll have to live
with all those inconsistencies.





reply via email to

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