From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Paul Pogonyshev <pogonyshev@gmail.com>
Cc: Emacs developers <emacs-devel@gnu.org>
Subject: Re: Signal `quit' in a `font-lock-fontify-region-function'
Date: Sat, 29 Jun 2019 17:26:02 -0400 [thread overview]
Message-ID: <jwv36jsm72h.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <CAG7BpaoqxLn+EX53aJTG=XXjek=kospJmtjC6DQmAXckXnB2tQ@mail.gmail.com> (Paul Pogonyshev's message of "Sat, 29 Jun 2019 19:50:13 +0200")
> I'm not sure if this is flexible enough. I don't like the idea of C-g
> already invoking some code (that e.g. disables font-locking).
In my suggestion, C-g wouldn't invoke any significant code. All it
would do is setup a timer, and when the timer expires a message would be
emitted in the echo area to inform the user what it is that Emacs is
currently doing.
It definitely wouldn't disable font-locking right away.
The disabling would only be in response to a "large" number of C-g,
which presumably should only be needed in extreme circumstances
(basically when currently the user ends up killing Emacs instead).
> So, I'd like to be able to _handle_ `quit' signal in the function
> itself and stop extending the region and return immediately, so that I
> don't throw away work on a considerable region of text that has been
> done already.
I don't understand why you say "don't throw away work on a considerable
region of text that has been done already": if you're in the middle of
extending the region, presumably no "work" has been done yet.
> However, fontlocking code shouldn't discard the results
> (as otherwise this is pointless). So, I cannot resignal `quit', I
> have to return normally. But I also don't want to "eat" this signal
> and hide C-g press from Emacs' monitoring code. So basically, I want
> font-locking still continue to work for a while, even if C-g has been
> pressed too many times, but if so, abort soon.
Could `while-no-input` be usable in this case?
> I'm not sure if it is the best solution, but I'd propose C-g to be
> counted not when `quit' signal is caught, but when it would be
> emitted, even if `inhibit-quit' is t. And font-locking code would
> look something like this:
>
> (let ((count-C-g-presses t)) ; Instead of "registering" as you
> proposed, I think we just
> ; need to tell C-g handler to count
> presses while inside
> ; certain blocks of code.
> (condition-case error
> (let ((fontified-region (funcall actual-handler ...)))
> ;; Process the fontified region
> ...)
> (error ;; This logs any errors inside the handler, including uncaught
> ;; `quit' signals. Just as now.
> ...))
> (when (too-many-C-g-recently) ; This would count both C-g that
> resulted in (signal 'quit ...)
> ; and those that resulted in
> `(setq quit-flag t)'.
I think if C-g resulted in (signal 'quit ...), then presumably we exited
this code, so the only really interesting case should be the one where
we just have `quit-flag` set to t.
Maybe we should change the C-g code so it sets `quit-flag` to the
number of C-g that are pending.
> ;; The below forms are roughly what would be "registered" in your
> ;; proposal. I feel leaving it up to the caller gives more
> ;; flexibility in actually permorming "abort everything" tasks.
> (setq font-lock-mode nil)
> (message "Too many C-g, font-locking disabled")))
Maybe when "registering", the code could provide a function to
execute instead of "aborting".
Stefan
next prev parent reply other threads:[~2019-06-29 21:26 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-29 17:50 Signal `quit' in a `font-lock-fontify-region-function' Paul Pogonyshev
2019-06-29 21:26 ` Stefan Monnier [this message]
2019-06-29 23:49 ` Paul Pogonyshev
2019-06-30 0:18 ` Stefan Monnier
2019-06-30 10:51 ` Paul Pogonyshev
-- strict thread matches above, loose matches on Subject: below --
2019-05-28 16:24 Paul Pogonyshev
2019-05-28 17:50 ` Stefan Monnier
2019-05-28 18:14 ` Paul Pogonyshev
2019-05-28 18:24 ` Stefan Monnier
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwv36jsm72h.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=emacs-devel@gnu.org \
--cc=pogonyshev@gmail.com \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.