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: Sat, 29 Jun 2019 19:50:13 +0200 [thread overview]
Message-ID: <CAG7BpaoqxLn+EX53aJTG=XXjek=kospJmtjC6DQmAXckXnB2tQ@mail.gmail.com> (raw)
Found this answer to my question in the list archives. I'm not
subscribed, please CC to me.
> Right, here's how I could imagine a "desirable" behavior:
>
> - everytime some operation may block Emacs, it should "register"
> somewhere (probably some let-binding of a global var is all it takes).
> - After hitting C-g, a timer is started.
> - If this timer is reached before the C-g has had to chance to be
> processed, emit a message in the echo area explaining what Emacs is
> currently doing (based on the "registered" information above).
> - when we reach the Nth C-g in a row within the same "registered"
> operation, we abort the operation (e.g. by calling an ad-hoc
> function provided while "registering").
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). Please
read on to see a usecase that I feel would be impossible to support
with your proposal.
My fontification function often extends the fontification region
considerably and then returns `(jit-lock-bounds START . END)', as
required in the documentation. In my case this makes fontification
much faster, because the function itself is very fast and most of the
time is spent in various setups (both in fontlocking code and the
function itself), not in traversing through the region to be
fontified.
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. 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.
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)'.
;; 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")))
I think I could try to implement this myself, but on the other hand
I'm certainly not familiar with Emacs internals. So I would gladly
give up this task to someone else who would like to do it.
Paul
next reply other threads:[~2019-06-29 17:50 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-29 17:50 Paul Pogonyshev [this message]
2019-06-29 21:26 ` Signal `quit' in a `font-lock-fontify-region-function' Stefan Monnier
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='CAG7BpaoqxLn+EX53aJTG=XXjek=kospJmtjC6DQmAXckXnB2tQ@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 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.