[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Kim F. Storm
Subject: Re: usr1-signal, usr2-signal, etc.
Date: Wed, 13 Dec 2006 11:26:53 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.91 (gnu/linux)

YAMAMOTO Mitsuharu <address@hidden> writes:

>>>>>> On Tue, 12 Dec 2006 14:54:06 +0100, address@hidden (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 <address@hidden> http://www.cua.dk

reply via email to

[Prev in Thread] Current Thread [Next in Thread]