[Top][All Lists]

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

Re: Signal `quit' in a `font-lock-fontify-region-function'

From: Paul Pogonyshev
Subject: Re: Signal `quit' in a `font-lock-fontify-region-function'
Date: Tue, 28 May 2019 18:24:52 +0200

Found this answer to my question in the list archives. I'm not
subscribed, please CC to me.

> > Error during redisplay: (jit-lock-function ##) signaled (quit)
> This is indeed the behavior I expect (tho I don't really like it, but
I never dared to change jit-lock to set inhibit-quit).
> > sometimes it doesn't.

Is there a difference in behavior in this respect when you try it in the
GUI vs in a tty?  How 'bout in another OS?

After recompiling with your patch I cannot reproduce it. Maybe it was
fixed by some other change, but more likely that I made a mistake and
the problem was never there. I could have been confused by my own
`message' replacement since it didn't insert at the buffer end, but
rather at the point.

Anyway, why I needed this. It is not impossible that during
development you write a fontification function that is broken and e.g.
falls into infinite loop. You can sort of abort it with C-g, but then
fontification code marks the whole region as unfontified (since the
function never finished), calls the function again, it gets stuck...
And the only way you can end this is by killing Emacs process. Or at
least I don't know any better way.

It is also possible to accidentally stumble into a finite, but
extremely long fontification. For example, if you open a
megabyte-large minified JavaScript file. I believe also one of the
many Python modes was susceptible at some point.

I was trying to write some workaround for my own mode, because it
targets log files, which can be hundreds of megabytes in size.
Additionally, the mode puts filtering into fontification process,
meaning that in fontification callback it can hide everything (if the
filter is too strict). And then the callback gets called again and
again, chewing through all the megabytes with no apparent way to stop
it until it finally finishes minutes later.

But would it make sense to adjust fontification code to disable
fontification in the current buffer if fontification function is
killed with C-g several times? I.e. instead of some custom workaround
for my mode only, add something generic to Emacs core. This would give
the user a chance to kill offending buffer rather than the whole


reply via email to

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