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

[Stefan Monnier]

> 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