Re: [PATCH] Unconditional quit on SIGUSR2

[Eli Zaretskii]

> Date: Mon, 28 Mar 2011 10:23:59 -0700
> From: Daniel Colascione <address@hidden>
> CC: address@hidden
> 
> >> Killing Emacs destroys any transient state. The last-resort-quit
> >> approach doesn't.
> > 
> > You originally said "save edits or debug Emacs", see above.
> > 
> > What transient state are we talking about?
> 
> I'm talking about any state not already written out to more permanent
> storage --- that includes not only unsaved buffer contents, but tramp
> sessions, window configurations, various histories, and so on.

Isn't that part of handling a fatal signal?

> (Speaking of debugging bytecode, by the way: would it be feasible to
> someday provide the ability to step through compiled functions
> bytecode-by-bytecode?)

I'm not sure I understand what you are suggesting here.  What I would
love is the ability to "disassemble" a Lisp backtrace, so that any
byte codes are converted into human-readable Lisp (or something
similar).  Perhaps there's already such a thing, who knows?

> >> can let users recover work and provide more detailed bug reports, as
> >> well as help us ferret out the cause of hard-to-reproduce lockups in
> >> font-lock code without having to run under a debugger all the time.
> > 
> > I'd like to hear what work can be recovered this way that is not
> > recovered by auto-save at fatal signal time.
> 
> Auto-save doesn't run continuously, and not everyone has it turned on.

I meant the automatic auto-save triggered by catching a fatal signal.
See emacs.c:fatal_error_signal.

> >> This way, we can hope to interrupt runaway font-lock code, and for
> >> this application, my proposed approach does indeed work.  If I could
> >> have implemented this feature without introducing additional
> >> machinery, I would have.
> > 
> > What prevents the implementation on the Lisp level of a feature that
> > could interrupt a runaway font-lock?
> 
> What Lisp-level method do you propose for breaking out of (let
> ((inhibit-quit t)) (while t)) ?

This isn't an interesting example.  I was talking about font-lock,
which I understand was the primary motivation for this patch.
Font-lock does not have such useless loops (I hope ;-).

I was asking about whatever you had in mind when you wished you could
implement such a feature without introducing additional machinery.
You tell me.