Re: [Emacs-diffs] master 6fdc3fa: Support terminal focus notifications

Re: [Emacs-diffs] master 6fdc3fa: Support terminal focus notifications

[Stefan Monnier]

> +(defun xterm-handle-focus-in ()
> +  (interactive)
> +  (handle-focus-in))
> +(defun xterm-handle-focus-out ()
> +  (interactive)
> +  (handle-focus-out))

Aka

    (defalias 'xterm-handle-focus-in  #'handle-focus-in)
    (defalias 'xterm-handle-focus-out #'handle-focus-out)

right?

> +(define-key global-map [xterm-focus-in] #'xterm-handle-focus-in)
> +(define-key global-map [xterm-focus-out] #'xterm-handle-focus-out)

I think this deserves a comment explaining why we don't use the
pre-existing `focus-in` and `focus-out` events and why we bind our
events in global-map rather than in special-map (as is done for
`focus-in/out` events).


        Stefan

Re: [Emacs-diffs] master 6fdc3fa: Support terminal focus notifications

[dancol]

>> +(defun xterm-handle-focus-in ()
>> +  (interactive)
>> +  (handle-focus-in))
>> +(defun xterm-handle-focus-out ()
>> +  (interactive)
>> +  (handle-focus-out))
>
> Aka
>
>     (defalias 'xterm-handle-focus-in  #'handle-focus-in)
>     (defalias 'xterm-handle-focus-out #'handle-focus-out)
>
> right?

handle-focus-{in,out} have an interactive specification that makes them
not work when bound directly to the synthetic event --- which seems silly,
since we never actually use the event --- but I didn't want to touch the
existing focus code.

>> +(define-key global-map [xterm-focus-in] #'xterm-handle-focus-in)
>> +(define-key global-map [xterm-focus-out] #'xterm-handle-focus-out)
>
> I think this deserves a comment explaining why we don't use the
> pre-existing `focus-in` and `focus-out` events and why we bind our
> events in global-map rather than in special-map (as is done for
> `focus-in/out` events).

I was being consistent with the xterm-paste event. All three events should
go in special-map if that's the right place, shouldn't they? It doesn't
seem to make a difference in this case.

Re: [Emacs-diffs] master 6fdc3fa: Support terminal focus notifications

[Stefan Monnier]

> handle-focus-{in,out} have an interactive specification that makes them
> not work when bound directly to the synthetic event --- which seems silly,
> since we never actually use the event --- but I didn't want to touch the
> existing focus code.

Ah, right.  We can fix the interactive spec not to signal an error.

>>> +(define-key global-map [xterm-focus-in] #'xterm-handle-focus-in)
>>> +(define-key global-map [xterm-focus-out] #'xterm-handle-focus-out)
>>
>> I think this deserves a comment explaining why we don't use the
>> pre-existing `focus-in` and `focus-out` events and why we bind our
>> events in global-map rather than in special-map (as is done for
>> `focus-in/out` events).
>
> I was being consistent with the xterm-paste event. All three events should
> go in special-map if that's the right place, shouldn't they?

The decision should not be based on the fact that they all come
from xterm.  I think xterm-paste wouldn't be right on special-map.

But to tell you the truth, I'm not completely sure what should go on
special-map and what shouldn't.

> It doesn't seem to make a difference in this case.

I think it makes a difference if you do:

    C-x <focus-out> <focus-in> C-c

[ My general rule of thumb for special-map is to think about what
  should happen if such events happen in the middle of
  a key-sequence.  ]


        Stefan

Re: [Emacs-diffs] master 6fdc3fa: Support terminal focus notifications

[dancol]

>>> +(defun xterm-handle-focus-in ()
>>> +  (interactive)
>>> +  (handle-focus-in))
>>> +(defun xterm-handle-focus-out ()
>>> +  (interactive)
>>> +  (handle-focus-out))
>>
>> Aka
>>
>>     (defalias 'xterm-handle-focus-in  #'handle-focus-in)
>>     (defalias 'xterm-handle-focus-out #'handle-focus-out)
>>
>> right?
>
> handle-focus-{in,out} have an interactive specification that makes them
> not work when bound directly to the synthetic event --- which seems silly,
> since we never actually use the event --- but I didn't want to touch the
> existing focus code.
>
>>> +(define-key global-map [xterm-focus-in] #'xterm-handle-focus-in)
>>> +(define-key global-map [xterm-focus-out] #'xterm-handle-focus-out)
>>
>> I think this deserves a comment explaining why we don't use the
>> pre-existing `focus-in` and `focus-out` events and why we bind our
>> events in global-map rather than in special-map (as is done for
>> `focus-in/out` events).
>
> I was being consistent with the xterm-paste event. All three events should
> go in special-map if that's the right place, shouldn't they? It doesn't
> seem to make a difference in this case.

Thanks for pointing out this inelegance. It prompted me to do some digging
and uncover a larger problem.

I agree that all three events should be in special-event-map. The trouble
is that only read-event consults special-event-map, and read-event doesn't
do event remapping, since it handles one low-level event at a time. I've
installed a change that does the moral equivalent of the special-event-map
handling (but inside read-key-sequence) by abusing function bindings in
the function key translation map.

Re: [Emacs-diffs] master 6fdc3fa: Support terminal focus notifications

[Stefan Monnier]

>> I think this deserves a comment explaining why we don't use the
>> pre-existing `focus-in` and `focus-out` events and why we bind our
>> events in global-map rather than in special-map (as is done for
>> `focus-in/out` events).
> I was being consistent with the xterm-paste event.  All three events should
> go in special-map if that's the right place, shouldn't they?  It doesn't
> seem to make a difference in this case.

BTW, I think it does make a difference: those events wouldn't work on
special-map because special-map is not looked up after input-decode-map.

So, I think ideally, we'd want to use special-map here, but for
technical reasons we can't.


        Stefan