From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Olaf Rogalsky Newsgroups: gmane.emacs.bugs Subject: bug#29150: Fwd: 26.0.90; Input decoding is sometimes skipped in TTY (xterm-mouse-mode) Date: Mon, 06 Nov 2017 22:43:11 +0100 Message-ID: <878tfjnkwg.fsf@t-online.de> References: <87y3nka4ez.fsf@t-online.de> <87wp34a2i1.fsf@t-online.de> <83y3njs8i1.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1510004654 4655 195.159.176.226 (6 Nov 2017 21:44:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 6 Nov 2017 21:44:14 +0000 (UTC) Cc: 29150@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Nov 06 22:44:10 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eBpBh-0000s5-9G for geb-bug-gnu-emacs@m.gmane.org; Mon, 06 Nov 2017 22:44:09 +0100 Original-Received: from localhost ([::1]:50374 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eBpBl-0005fL-NB for geb-bug-gnu-emacs@m.gmane.org; Mon, 06 Nov 2017 16:44:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48413) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eBpBf-0005eO-Ca for bug-gnu-emacs@gnu.org; Mon, 06 Nov 2017 16:44:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eBpBa-0004qK-Di for bug-gnu-emacs@gnu.org; Mon, 06 Nov 2017 16:44:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:46031) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eBpBa-0004qE-9e for bug-gnu-emacs@gnu.org; Mon, 06 Nov 2017 16:44:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eBpBa-0008NM-1O for bug-gnu-emacs@gnu.org; Mon, 06 Nov 2017 16:44:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Olaf Rogalsky Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Nov 2017 21:44:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29150 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 29150-submit@debbugs.gnu.org id=B29150.151000462332162 (code B ref 29150); Mon, 06 Nov 2017 21:44:01 +0000 Original-Received: (at 29150) by debbugs.gnu.org; 6 Nov 2017 21:43:43 +0000 Original-Received: from localhost ([127.0.0.1]:54712 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eBpBH-0008Mg-Bm for submit@debbugs.gnu.org; Mon, 06 Nov 2017 16:43:43 -0500 Original-Received: from mailout06.t-online.de ([194.25.134.19]:55220) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eBpBF-0008MX-D7 for 29150@debbugs.gnu.org; Mon, 06 Nov 2017 16:43:41 -0500 Original-Received: from fwd12.aul.t-online.de (fwd12.aul.t-online.de [172.20.26.241]) by mailout06.t-online.de (Postfix) with SMTP id F2DA641CFECF; Mon, 6 Nov 2017 22:43:39 +0100 (CET) Original-Received: from blaubaer (rIJ--sZJ8hQHPzB7ecKu1QXzNeU5gATDctokM6xUCD9xxaSwwEkB8gpgNdcEZ5MgDU@[84.57.184.143]) by fwd12.t-online.de with (TLSv1.2:DHE-RSA-AES256-SHA256 encrypted) esmtp id 1eBpBC-1mDJLc0; Mon, 6 Nov 2017 22:43:38 +0100 In-reply-to: <83y3njs8i1.fsf@gnu.org> X-ID: rIJ--sZJ8hQHPzB7ecKu1QXzNeU5gATDctokM6xUCD9xxaSwwEkB8gpgNdcEZ5MgDU X-TOI-MSGID: 666db8bd-9a33-4b08-8c3f-ee6cfe432dfe X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:139528 Archived-At: Eli Zaretskii writes: >> in case of a button down event, `describe-key' has some trickery to also >> read the forthcoming up event. The following patch makes this trickery >> work with xterm-mouse-mode. > > Thanks. Do you understand why read-key-sequence-vector works with > xt-mouse, while read-event doesn't? If so, can you elaborate on that? Unlike read-key-sequence and read-key-sequence-vector, read-event does not use input-decode-map. xterm-mouse-mode relies on input-decode-map to convert special byte sequences (starting with "\e[") into proper mouse events. read-event stops reading after the first character ("\e") of the byte sequence -- the remaining charcters are then inserted into the current buffer. > Also, I take it that you assume there will be only one element in the > array returned by read-key-sequence-vector, is that right? If so, how > sure are we that this will always be the case? Because if the > assumption could be false, this change will have Emacs wait for some > other input, and the user might think that Emacs hanged. Yes, that was my assumption. read-key-sequence-vector is called after a mouse-down event was read. If someone presses a prefix key before releasing the mouse or if the up event is a prefix to some binding, then strange things may happen. I wasn't able to think of and construct a case, in which, after the user releases the mouse button, read-key-sequence-vector still tries to read additional characters. In any case, \C-g will interrupt read-key-sequence-vector. But see below. > Anyway, in general, I'm wary of such changes, which replace one API > for reading input by another, which works subtly differently. We had > in the recent past several incidents where similar changes seemed to > work, only to reveal many moons later that some rarely-used but useful > functionality stopped working or became semi-broken. So I think I'd > prefer a fix that is specific to xt-mouse (assuming that we can > reliably detect that the clicks come from xt-mouse), and leave the > other use cases alone. If such a solution is possible and makes > sense, we could even install it on the release branch. If you are still not convinced, that read-key-sequence-vector is harmless, then please find a modified patch below. There I check, as suggested, that the mouse-down event under consideration was generated by xterm-mouse-mode. This is quite easy to accomplish, because xterm-mouse anyway remembers the last mouse-down event in a terminal paramerter. diff --git a/lisp/help.el b/lisp/help.el index bc8035db0e..fbb9fc8cbe 100644 --- a/lisp/help.el +++ b/lisp/help.el @@ -717,7 +717,7 @@ help-read-key-sequence (cursor-in-echo-area t) saved-yank-menu) (unwind-protect - (let (key) + (let (key down-ev) ;; If yank-menu is empty, populate it temporarily, so that ;; "Select and Paste" menu can generate a complete event. (when (null (cdr yank-menu)) @@ -743,17 +743,21 @@ help-read-key-sequence (let ((last-idx (1- (length key)))) (and (eventp (aref key last-idx)) (memq 'down (event-modifiers (aref key last-idx))))) - (or (and (eventp (aref key 0)) - (memq 'down (event-modifiers (aref key 0))) + (or (and (eventp (setq down-ev (aref key 0))) + (memq 'down (event-modifiers down-ev)) ;; However, for the C-down-mouse-2 popup ;; menu, there is no subsequent up-event. In ;; this case, the up-event is the next ;; element in the supplied vector. (= (length key) 1)) (and (> (length key) 1) - (eventp (aref key 1)) - (memq 'down (event-modifiers (aref key 1))))) - (read-event)))) + (eventp (setq down-ev (aref key 1))) + (memq 'down (event-modifiers down-ev)))) + (if (and (terminal-parameter nil 'xterm-mouse-mode) + (equal (terminal-parameter nil 'xterm-mouse-last-down) + down-ev)) + (aref (read-key-sequence-vector nil) 0) + (read-event))))) ;; Put yank-menu back as it was, if we changed it. (when saved-yank-menu (setq yank-menu (copy-sequence saved-yank-menu)) >> PS: It would be nice, if that person also can have a look at patch #29104 > > It's in my queue, if no one else beats me to it. And there, too, more > detailed description of what you saw and what led you to your proposed > solution might go a long way towards admitting the change sooner. Thanks a lot. I will comment on that patch in a separate email. Olaf -- Olaf Rogalsky Schwörhausgasse 5 89073 Ulm Germany