Re: usr1-signal, usr2-signal, etc.

[storm@cua.dk (Kim F. Storm)]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

>>>>>> On Tue, 12 Dec 2006 14:54:06 +0100, storm@cua.dk (Kim F. Storm) said:
>
>>>> What if the signal handlers just increment a global counter (one
>>>> for each signal type), and the main loop in keyboard.c checked
>>>> those counters and added the pending signal events in the "safe
>>>> context"?
>>> 
>>> There're two problems I can think of with this approach.
>
>> You are absolutely right about those problems, but they both existed
>> before.  In both cases, they only mean a delay in delivering the
>> signal event, which already was a problem in the original code.
>
> I tried minimizing the first problem, but the second one still
> remains.

Thank you very much.

The changes look good, so please install them.

>
> BTW, is it necessary for us to read these events by read-key-sequence?
> If not, it looks natural to bind them in special-event-map.

You have a good point there!  If we bind signals in special-event-map,
we don't really have to care about them being mixed up with the rest
of the keyboard events ...

OTOH, if we put them in the special-event-map, we make it practically
impossible for a (global) minor-mode to setup catching a signal
through its "private" keymaps.  So keeping signals in the
read-key-sequence loop is definitely more flexible.

Also, although the definition of special-event-map doesn't explicitly
say so, it only allows bindings for single events.  This means that we
would have to revert to having just a single event for signals.

So I suggest installing your changes, and otherwise keep things as they are.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk