From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jared Finder via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: Additional cleanup around xterm-mouse Date: Sun, 27 Dec 2020 08:30:44 -0800 Message-ID: <90ff03cd289ec32998b44bb486b32d5e@finder.org> References: Reply-To: Jared Finder Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39345"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Roundcube Webmail/1.3.15 Cc: Eli Zaretskii , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Dec 27 17:31:50 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ktYxR-000A7z-Fn for ged-emacs-devel@m.gmane-mx.org; Sun, 27 Dec 2020 17:31:49 +0100 Original-Received: from localhost ([::1]:47730 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ktYxQ-00074G-En for ged-emacs-devel@m.gmane-mx.org; Sun, 27 Dec 2020 11:31:48 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41874) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ktYwV-0006ad-5S for emacs-devel@gnu.org; Sun, 27 Dec 2020 11:30:52 -0500 Original-Received: from greenhill.hpalace.com ([2600:3c01::f03c:91ff:fe73:2daa]:58814) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ktYwS-0007X9-Qs; Sun, 27 Dec 2020 11:30:50 -0500 Original-Received: from mail.finder.org (greenhill.hpalace.com [IPv6:2600:3c01::f03c:91ff:fe73:2daa]) by greenhill.hpalace.com (Postfix) with ESMTPSA id 28B935BB; Sun, 27 Dec 2020 16:30:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=finder.org; s=2018; t=1609086645; bh=hKQ5SXBTLQ+OrhhhPPUqGEXpLRVh3bbbk9kJK9TkhCk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=sCEHZg7gJqE3txcdHTr9Naah8DE5gUJBDAAiuLqODItcFiG47chr3g2CFsLvnxohL igAfULDHEm1O4C8fbE8ya4Exwer23RUsEx3ONOVQnejEvrDlJIA4Hd3MMKfr9fRU+R DARzy7m11Vba0tQ9UeJbtW8058397O+f6DL1rK1d59vP4Xv1beCdrEZsStAn3FSFfy x2MD1m/LfYdRUXxbIsG5iV9XGzNB8L1xxY4cA9QNPAp4WIm4QsCSq25X7Uj6NGVYLF PAKpfMqWM//4r/Ots4s987jwg2TWcRyWX6VplLKNDz8vm/avknp585mtdo13nvSa3R KhjWEAOnLnIng== In-Reply-To: X-Sender: jared@finder.org Received-SPF: pass client-ip=2600:3c01::f03c:91ff:fe73:2daa; envelope-from=jared@finder.org; helo=greenhill.hpalace.com X-Spam_score_int: 12 X-Spam_score: 1.2 X-Spam_bar: + X-Spam_report: (1.2 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:261906 Archived-At: On 2020-12-27 7:36 am, Stefan Monnier wrote: >> -@defun read-key &optional prompt >> +@defun read-key &optional prompt all-fallbacks-disabled > > FWIW, I would call it "fallbacks-disabled". I want to distinguish it from the very similar intentioned but somewhat differing behaving parameter to read-key-sequence. If I don't need to change read-key-sequence's behavior (see below), then I am 100% on board. > Hmm... now that I think about it, I wonder if we need to make changes > in > `read_key_sequence` at all, because we can instead arrange for all keys > to be bound: > > diff --git a/lisp/subr.el b/lisp/subr.el > index 725722cbee..1ca1d51d44 100644 > --- a/lisp/subr.el > +++ b/lisp/subr.el > @@ -2453,10 +2453,11 @@ memory-limit > ;;;; Input and display facilities. > > (defconst read-key-empty-map (make-sparse-keymap)) > - > +(defconst read-key-full-map > + (let ((map (make-sparse-keymap))) (define-key map [t] 'dummy) > map)) > (defvar read-key-delay 0.01) ;Fast enough for 100Hz repeat rate, > hopefully. > > -(defun read-key (&optional prompt) > +(defun read-key (&optional prompt dont-fallback) > "Read a key from the keyboard. > Contrary to `read-event' this will not return a raw event but > instead will > obey the input decoding and translations usually done by > `read-key-sequence'. > @@ -2468,7 +2469,8 @@ read-key > ;; always inherits the input method, in practice read-key does > not > ;; inherit the input method (at least not if it's based on > quail). > (let ((overriding-terminal-local-map nil) > - (overriding-local-map read-key-empty-map) > + (overriding-local-map > + (if dont-fallback read-key-full-map read-key-empty-map)) > (echo-keystrokes 0) > (old-global-map (current-global-map)) > (timer (run-with-idle-timer > > WDYT? This needs to also avoid binding ESC as well, e.g. adding (define-key map [?\e] nil). Cursory testing locally with that as well shows this working out well. This assumes that ESC is the only prefix key in input-decode-map. Is that an okay assumption to make? It appears true locally on my xterm. All other suggestions integrated into my local patch. -- MJF