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: Thu, 03 Dec 2020 09:31:18 -0800 Message-ID: <106c6d31ef09b83042ef0fab5ac0ed88@finder.org> References: <83o8jupnqd.fsf@gnu.org> <838savys2v.fsf@gnu.org> <3e3933d8ec1d5d3f6809385a8ac5f447@finder.org> <83mtz1moa5.fsf@gnu.org> <0ea60a4f2a7fb0698f84ac5957cafef3@finder.org> <83mtyxgzck.fsf@gnu.org> <2eac7957a7c20af3517a3ad0862a5b39@finder.org> 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="19127"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Roundcube Webmail/1.3.15 Cc: "Jared Finder via \"Emacs development discussions.\"" , Eli Zaretskii To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 03 18:38:54 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 1kksZC-0004ri-Co for ged-emacs-devel@m.gmane-mx.org; Thu, 03 Dec 2020 18:38:54 +0100 Original-Received: from localhost ([::1]:54062 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kksZB-0008KS-EL for ged-emacs-devel@m.gmane-mx.org; Thu, 03 Dec 2020 12:38:53 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57402) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kksS0-0004KY-LM for emacs-devel@gnu.org; Thu, 03 Dec 2020 12:31:34 -0500 Original-Received: from greenhill.hpalace.com ([2600:3c01::f03c:91ff:fe73:2daa]:55914) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kksRv-00068T-KI; Thu, 03 Dec 2020 12:31:27 -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 25D695D; Thu, 3 Dec 2020 17:31:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=finder.org; s=2018; t=1607016679; bh=LyJLtd2oEDWMlagzBLGYbk11LVi2MBaJ/OHTMSJQVhw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=oiDTNJXqrcIKOlpO/FePB92unDwfvBHwIkY7fTxxRFjaJlUvtdZ61TBd05VRnTJE5 WW57tv1h9o/IQ0ORJnru4vUevRJdmKYxaw02W4OpZhOTzvMPvpsrY3dN31X/KqmfeG oQVACr4X8e8sX+tU1prrslKnhUK4QxZQlvc2ufrn3Ed9UVUfdnYHmZfgs8UBAc/SKJ a7Hr5kjLxD5JZU6nsZO8r2E9NgdgEfGsiqsDwDwz2jfDmDAiNe72FUJayRE4qzYtHc 2DYVT3nIf1w41qMu9rBUjFVA0CPAD2fjSyiCj/iSQCdAmRNBxV7YMDbEsjFD7FPrjb OBJKD6E9DfcMw== 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:260232 Archived-At: On 2020-12-03 6:45 am, Stefan Monnier wrote: > Jared Finder [2020-12-02 21:46:53] wrote: > >> On 2020-12-02 8:53 am, Stefan Monnier wrote: >>>> Subject: [PATCH] Make libraries work with xterm-mouse-mode. >>> Could you explain (at least in the code, and ideally here as well) >>> why >>> we need this new `all-mouse-events` behavior? >> >> I updated the function locally to look like as follows. Let me know >> if you >> have further questions. >> >> (defun read-potential-mouse-event () >> "Read an event that might be a mouse event. >> >> This function exists for backward compatibility in code packaged >> with Emacs. Do not call it directly in your own packages." >> ;; `xterm-mouse-mode' events must go through `read-key' as they >> ;; are decoded via `input-decode-map'. >> (if xterm-mouse-mode >> (read-key nil >> ;; Normally `read-key' discards all mouse button >> ;; down events. However, we want them here. >> t) >> (read-event))) > > That doesn't say what this function should do with non-mouse events, so > it makes it hard to decide what its behavior should be. > > OK, so what you specifically need is for down events not to be > dropped, right? I want no mouse event to get dropped (drag events also get dropped, right?) and no mouse events to get degraded to simpler forms. In summary, I want mouse events to get returned unprocessed, as if from read-event, but with input-decode-map applied. The alternative I presented further up in the thread was to apply input-decode-map manually to successive calls to read-event. I got this working, though it sounded like modifying read-key was preferred earlier in this thread. For context, here's the alternative: (defun read-decoded-key () "Read a single key, as if by `read-key'. Unlike `read-key', this does not call `read-key-sequence' and instead has a bare-bones implementation of its functionality. In particular, it applies `input-decode-map' but does not apply `local-function-key-map' or `input-translation-map'." (let* ((keys '()) (decoder input-decode-map) (echo-keystrokes 0) (timer (run-with-idle-timer read-key-delay t (lambda () (unless (null keys) (throw 'read-decoded-key nil))))) result) (catch 'read-decoded-key (unwind-protect (while t (let ((next-key (read-event))) (push next-key keys) (setq decoder (lookup-key decoder (vector next-key)))) (when (pcase decoder ;; A direct decoding (common for function keys) ((pred arrayp) (setq result decoder)) ;; A function that does decoding (like for ;; `xterm-mouse-mode') ((pred functionp) (setq result (funcall decoder nil)))) (if (zerop (length result)) ;; The decoding is an empty vector to say "continue ;; reading". This happens when the key would be ;; mouse-movement but `track-mouse' is nil. (setq keys '() decoder input-decode-map) (throw 'read-decoded-key nil)))) (cancel-timer timer))) ;; If no decoding, the accumulated keys are the result. (or result (vconcat (nreverse keys))))) >>> `function-key-map` has very similar effects (and to a large extent, >>> the >>> downgrading of mouse-down events controlled by `all-mouse-events` >>> could >>> (I'd even say should) be implemented in `function-key-map` rather >>> than >>> via the current ad-hoc code in read-key-sequence), so I'm not very >>> comfortable with treating these mouse-event-rewritings differently >>> from >>> other rewritings. >> Just a few comments: >> Wouldn't that require binding 2^6 * 3 * 3 * 5 = 2880 events in >> function-key-map? > > Yes, but that's only because of the limited form available in keymaps. > To make it practical, we'd need to add "computed keymaps". This is > a long-standing desire of mine, which would be useful in various > circumstances (and should make it possible to remove a lot of ad-hoc > rewritings in read_key_sequence). Makes sense. I think the easiest way to do this would be to allow keymaps to have multiple conditional fallbacks. Perhaps allow a binding in a keymap to be a hook that runs via `run-hook-with-args-until-success'? It's a slight generalization of the current logic which allows functions. Technically this can be done now with just a layer of indirection on the [t] binding in a keymap. >> And such behavior would want a special variable (as the code is >> currently in >> my patch) to disable it to avoid copying all of function-key-map in >> read-key. So I think it is fully independent of my current patch. > > Yes. My point is just that a functionally "don't discard mouse-events" > is weird in a function which is not specifically about mouse events. > It naturally leads to "don't down case events", "don't remap `tab` to > TAB", etc... > There has to be a more general underlying principle. > > Maybe we could (re)use the DONT-DOWNCASE-LAST arg of > `read-key-sequence` > for that? This would mean no change in `read-key` but a change in > `read-key-sequence` instead (and hence further-reaching consequences). > > Or maybe an option to `read-key` to disable all > function-key-map-like remappings (i.e. remappings which are only > applied > if there's no binding for that key-sequence)? One way to do this would be to add new behavior if DONT-DOWNCASE-LAST is a list. In other words, if DONT-DOWNCASE-LAST is non-nil and not a list, existing behavior. But if DONT-DOWNCASE-LAST is a list, we can look at the members of the list to determine what to do. This is a slight change in existing behavior, but it is very unlikely to break anything. -- MJF