problem with font lock

problem with font lock

[Jose A. Ortega Ruiz]

hi,

i'm experiencing an intermittent problem with font lock that i don't
know how to debug (this is emacs 23.1.91 packaged for debian). every now
and then, font lock just stops working in most (but not all) of the
buffers: the extant colors remain, but new text is not coloured at all
(e.g., if i comment a line out, the line's text retains its initial
faces instead of switching to the comment face). as i said, i haven't
found a way to reproduce this behaviour deterministically, and when it
starts happening i don't see any error message around. so my question
is: what would you recommend to look at when i enter this state, so that
i can submit a useful bug report?

thanks!
jao

Re: problem with font lock

[Stefan Monnier]

> i'm experiencing an intermittent problem with font lock that i don't
> know how to debug (this is emacs 23.1.91 packaged for debian). every now
> and then, font lock just stops working in most (but not all) of the
> buffers: the extant colors remain, but new text is not coloured at all
> (e.g., if i comment a line out, the line's text retains its initial
> faces instead of switching to the comment face). as i said, i haven't
> found a way to reproduce this behaviour deterministically, and when it
> starts happening i don't see any error message around. so my question
> is: what would you recommend to look at when i enter this state, so that
> i can submit a useful bug report?

Once it's done it's too late.  But you can (setq font-lock-support-mode
nil) in your .emacs and then try to reproduce the problem.  This should
(well, may) give you a usable error message right when the
problem appears.


        Stefan

Re: problem with font lock

[Eli Zaretskii]

> From: "Jose A. Ortega Ruiz" <jao@gnu.org>
> Date: Fri, 15 Jan 2010 13:14:09 +0100
> 
> i'm experiencing an intermittent problem with font lock that i don't
> know how to debug (this is emacs 23.1.91 packaged for debian). every now
> and then, font lock just stops working in most (but not all) of the
> buffers: the extant colors remain, but new text is not coloured at all
> (e.g., if i comment a line out, the line's text retains its initial
> faces instead of switching to the comment face). as i said, i haven't
> found a way to reproduce this behaviour deterministically, and when it
> starts happening i don't see any error message around. so my question
> is: what would you recommend to look at when i enter this state, so that
> i can submit a useful bug report?

Did you customize font-lock or jit-lock in any way?  Does this happen
in "emacs -Q"?  If you type "M-x font-lock-fontify-buffer RET", after
e.g., commenting a line, does the fontification catch up with the
changes?

Re-fontification when the buffer is modified or scrolled is done by
jit-lock.el, and it generally runs off Emacs timers.  So anything that
prevents times from running would have the effect that you seem to
observe.

Re: problem with font lock

[alin.s]

begin by understanding which module tries to paint the region you expect.

There are many different  : overlays, font-lock based on classes of syntax,
font-lock based on regular expressions, etc.

You must have patience and discover which of these modules paints every
character/word from the buffer where you are interested.

Look into the elisp manual.

When you comment a line you should expect that the author of the minor/major
modes actives defined the fontification using the font lock for the
"comment" syntax class; its color is defined in font-lock-comment-face'. But
it is not sure that the commented line was fontified so.





Jose A. Ortega Ruiz-2 wrote:
> 
> 
> hi,
> 
> i'm experiencing an intermittent problem with font lock that i don't
> know how to debug (this is emacs 23.1.91 packaged for debian). every now
> and then, font lock just stops working in most (but not all) of the
> buffers: the extant colors remain, but new text is not coloured at all
> (e.g., if i comment a line out, the line's text retains its initial
> faces instead of switching to the comment face). as i said, i haven't
> found a way to reproduce this behaviour deterministically, and when it
> starts happening i don't see any error message around. so my question
> is: what would you recommend to look at when i enter this state, so that
> i can submit a useful bug report?
> 
> thanks!
> jao
> 
> 
> 
> 
> 

-- 
View this message in context: http://old.nabble.com/problem-with-font-lock-tp27176810p27179603.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: problem with font lock

[Jose A. Ortega Ruiz]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Jose A. Ortega Ruiz" <jao@gnu.org>
>> Date: Fri, 15 Jan 2010 13:14:09 +0100
>> 
>> i'm experiencing an intermittent problem with font lock that i don't
>> know how to debug (this is emacs 23.1.91 packaged for debian). every now
>> and then, font lock just stops working in most (but not all) of the
>> buffers: the extant colors remain, but new text is not coloured at all
>> (e.g., if i comment a line out, the line's text retains its initial
>> faces instead of switching to the comment face). as i said, i haven't
>> found a way to reproduce this behaviour deterministically, and when it
>> starts happening i don't see any error message around. so my question
>> is: what would you recommend to look at when i enter this state, so that
>> i can submit a useful bug report?
>
> Did you customize font-lock or jit-lock in any way?

I'm using customize themes that include many, many font lock faces;
other than that no.

> Does this happen in "emacs -Q"?

I don't know. It only happens after periods of days using emacs, and i
cannot afford that long without my customizations and other packages.

> If you type "M-x font-lock-fontify-buffer RET", after e.g., commenting
> a line, does the fontification catch up with the changes?

Yes, it does.

> Re-fontification when the buffer is modified or scrolled is done by
> jit-lock.el, and it generally runs off Emacs timers.  So anything that
> prevents times from running would have the effect that you seem to
> observe.

Sounds reasonable, specially since font-lock-fontify-buffer still works.
For now, i'll apply Stephan's advice and try to see if i reach the
condition with font-lock-support-mode disabled.

Thanks!

jao
-- 
There are two ways to write error-free programs; only the third one
works.
  - Alan Perlis, Epigrams in Programing

Re: problem with font lock

[Stefan Monnier]

> Sounds reasonable, specially since font-lock-fontify-buffer still works.
> For now, i'll apply Stephan's advice and try to see if i reach the
> condition with font-lock-support-mode disabled.

BTW, you'll also want (setq debug-on-error t) so that when the error
happens you get a useful backtrace.


        Stefan

Re: problem with font lock

[Jose A. Ortega Ruiz]

"alin.s" <alinsoar@voila.fr> writes:

> begin by understanding which module tries to paint the region you expect.
>
> There are many different  : overlays, font-lock based on classes of syntax,
> font-lock based on regular expressions, etc.
>
> You must have patience and discover which of these modules paints every
> character/word from the buffer where you are interested.
>
> Look into the elisp manual.
>
> When you comment a line you should expect that the author of the minor/major
> modes actives defined the fontification using the font lock for the
> "comment" syntax class; its color is defined in font-lock-comment-face'. But
> it is not sure that the commented line was fontified so.

When it appears, the problem happens with many different modes (elisp,
c, c++, my own variants of those two, haskell, scheme) and not only
for comments: fontification of any syntactical element only happens when
explicitly requested. So looking for a problem with font lock sounds as
a good, if not sure, bet for now.

Thanks for the advice!
jao

Re: problem with font lock

[Jose A. Ortega Ruiz]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> Once it's done it's too late.  But you can (setq font-lock-support-mode
> nil) in your .emacs and then try to reproduce the problem.  This should
> (well, may) give you a usable error message right when the
> problem appears.

Although setting font-lock-support-mode to nil (and debug-on-error
active) didn't trigger an error, i think i've located the origin of the
problem. i have a little DSL for specifying faces for custom themes, and
i was setting one of the faces to a non-sensical value (concretely, the
face was fringe, and i was setting its :foreground to a list specifiying
a full face, instead of just a color or similar). upon correcting the
face specification and re-enabling my custom theme, the buffers that had
lost their real-time fontification recovered it instantaneously. maybe
someone privy to font-lock will understand why a bogus face
specification would have such a global effect. (BTW, the problem was
also occurring in emacs 23.1.1.)

Thanks!
jao