bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#9919: 24.0.91; font-lock broken in dired


From: Stefan Monnier
Subject: bug#9919: 24.0.91; font-lock broken in dired
Date: Mon, 09 Jan 2012 17:36:51 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux)

>> > I am still getting reports about this wrt dired+.el from users on
>> > GNU/Linux.  So perhaps my workaround is not sufficient there - dunno.
>> Whenever you change font-lock-defaults, you need to cause
>> font-lock-keywords (and the text already font-locked) to be refreshed,
>> unless you know for sure that font-lock-mode has not yet been started.
> Your "whenever" obviously does not apply to Emacs 20-22, since
> `font-lock-refresh-defaults' does not even exist in those releases.

It does: notice I don't mention font-lock-refresh-defaults which merely
makes it easy (it was introduced just to make it easier to solve this
problem).

> And at least for my code, "whenever" is true only for Emacs 24, not
> Emacs 23 (which also has `font-lock-refresh-defaults').  And the
> problem did not exist in Emacs 24 either, until the build where
> I reported the bug.

No, your code was wrong and always has been: you change
only font-lock-defaults, whereas you do not know for a fact that
font-lock-mode has not yet been enabled.
In earlier Emacsen, in normal circumstances, you just got lucky.

> I have this code, which has always worked and still works with Emacs
> 20 through 23.3:

Code that works in practice doesn't mean correct code.

> (add-hook
>   'dired-mode-hook
>   (lambda ()
>     (set (make-local-variable 'font-lock-defaults)
>          (cons '(dired-font-lock-keywords diredp-font-lock-keywords-1)
>                (cdr font-lock-defaults)))

Great.  Now after running the above code, the user adds

  (add-hook 'dired-mode-hook (lambda () (font-lock-mode 1)))

and suddenly the bug shows up even in Emacs-23.

>> I don't see any evidence of a performance problem.
> This means, in effect, that fontification must now be done twice, or
> else it is incorrect.  That's the performance hit I meant:
> font-locking twice.

Evidence of a performance problem requires measures, times, things
like that.  You're talking about some hypothetical problem based on your
understanding of how things work.  Things don't always work the way we
think they do.  We have plenty of hypothetical performance problems in
Emacs that I'm not going to worry about them.

> What's the cause of this change/regression?

Nothing very deep.  The moment when font-lock-mode gets enabled
has changed.  I'm not convinced the new time is really much better, but
I'm not convinced the old time was better either.  Basically it used to
be enabled after running the mode hook, which made it
difficult to disable font-lock-mode via a mode-hook check, wherea now it
gets enabled before, so you can just do

  (add-hook 'dired-mode-hook (lambda () (if foo (font-lock-mode -1))))


-- Stefan





reply via email to

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