unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Paul Pogonyshev <pogonyshev@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>,
	Emacs developers <emacs-devel@gnu.org>
Subject: Re: Signal `quit' in a `font-lock-fontify-region-function'
Date: Tue, 28 May 2019 18:24:52 +0200	[thread overview]
Message-ID: <CAG7Bpaq5YYJbtUGC5s4wAXjjL0RhquDWnWDuhUOxKUYX84PrwA@mail.gmail.com> (raw)

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
Emacs.

Paul



             reply	other threads:[~2019-05-28 16:24 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-28 16:24 Paul Pogonyshev [this message]
2019-05-28 17:50 ` Signal `quit' in a `font-lock-fontify-region-function' Stefan Monnier
2019-05-28 18:14   ` Paul Pogonyshev
2019-05-28 18:24     ` Stefan Monnier
  -- strict thread matches above, loose matches on Subject: below --
2019-06-29 17:50 Paul Pogonyshev
2019-06-29 21:26 ` Stefan Monnier
2019-06-29 23:49   ` Paul Pogonyshev
2019-06-30  0:18     ` Stefan Monnier
2019-06-30 10:51       ` Paul Pogonyshev
2019-05-16 22:20 Paul Pogonyshev
2019-05-16 23:20 ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAG7Bpaq5YYJbtUGC5s4wAXjjL0RhquDWnWDuhUOxKUYX84PrwA@mail.gmail.com \
    --to=pogonyshev@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).