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

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 13 Dec 2006 11:26:53 +0100, address@hidden (Kim F. Storm) said:

>> I tried minimizing the first problem, but the second one still
>> remains.

> Thank you very much.

> The changes look good, so please install them.

Done.

>> 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 ...

Yes.  The Emacs Lisp info says:

  `signal usr1'
  `signal usr2'
       These event sequences are generated when the Emacs process receives
       the signals `SIGUSR1' and `SIGUSR2'.  They contain no additional
       data because signals do not carry additional information.

     If one of these events arrives in the middle of a key sequence--that
  is, after a prefix key--then Emacs reorders the events so that this
  event comes either before or after the multi-event key sequence, not
  within it.

But currently they do not behave as above.

> 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.

One possible way would be to generate an intermediate single event
that carries a signal number, and bind such an event to a dispatcher
command in special-event-map.  Then the dispatcher looks up the
corresponding (multiple) key sequence and executes the associated
command.  `mac-dispatch-apple-event' in term/mac-win.el handles Apple
Events in such a way so these events may not be mixed up with a usual
key sequence.

                                     YAMAMOTO Mitsuharu
                                address@hidden