[Top][All Lists]

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

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

From: dancol
Subject: Re: [Emacs-diffs] master 6fdc3fa: Support terminal focus notifications
Date: Sat, 9 Jun 2018 13:19:54 -0700
User-agent: SquirrelMail/1.4.23 [SVN]

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

reply via email to

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