GNU bug report logs - #45834
28.0.50; Mouse events in terminal emacs

Previous Next

Full log

Message #26 received at 45834 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 45834 <at> debbugs.gnu.org
Subject: Re: bug#45834: 28.0.50; Mouse events in terminal emacs
Date: Wed, 08 Sep 2021 11:34:04 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

>> Does this work in Emacs 27?  If it does, I suspect one of the recent
>> changes in the input handling stuff...
>
> No, Emacs 27 also has the same problem.  Emacs 26.1 does not, though.

Poking at this a bit more -- the translation of these events apparently
relied on some magic in `read-event':

    ;; These translation functions actually call the focus handlers            
    ;; internally and return an empty sequence, causing us to go on to         
    ;; read the next event.                                                    
    (define-key map "\e[I" #'xterm-translate-focus-in)

;; By returning an empty key sequence, these two functions perform the         
;; moral equivalent of the kind of transparent event processing done           
;; by read-event's handling of special-event-map, but inside                   
;; read-key-sequence (which can recognize multi-character terminal             
;; notifications) instead of read-event (which can't).                         

(defun xterm-translate-focus-in (_prompt)
  (setf (terminal-parameter nil 'tty-focus-state) 'focused)
  (funcall after-focus-change-function)
  [])

This works in Emacs 26.1, but not Emacs 27.1.  I've stared at the
changes in read_key_sequence, but nothing seemed immediately suspicious
here... 

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.