From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Additional xterm-mouse cleanup Date: Tue, 02 Feb 2021 09:37:39 -0500 Message-ID: References: <4ab742d461a50a1b9a0debba781a18ad@finder.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18408"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: "jared--- via \"Emacs development discussions.\"" To: Jared Finder Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Feb 02 16:00:40 2021 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 1l6xAW-0004hu-9d for ged-emacs-devel@m.gmane-mx.org; Tue, 02 Feb 2021 16:00:40 +0100 Original-Received: from localhost ([::1]:39962 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l6xAV-0007dj-8k for ged-emacs-devel@m.gmane-mx.org; Tue, 02 Feb 2021 10:00:39 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46408) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l6woN-00057S-5M for emacs-devel@gnu.org; Tue, 02 Feb 2021 09:37:47 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:31461) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l6woK-0007h9-Kq for emacs-devel@gnu.org; Tue, 02 Feb 2021 09:37:46 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 368CC101134; Tue, 2 Feb 2021 09:37:43 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 6C8D210021D; Tue, 2 Feb 2021 09:37:41 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1612276661; bh=GxRK7j2h2TY5J2Mnj/V4GYEbqCGUuqo36fkCIU3byps=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=Nmbyk6KB+2tptEWQJLw2ICzmF39Qg8ewPpx9tKrYh18d73pgSxlQ37c7EyCqyBy3O 7eLAPY2gQ1f5fvfbtAoVqeHKuuKkRZTq5D6uMC4VkV/6vQAzGX9PXlgfPDvb68jYxt sIABst5gls7zm9At63uJu3yj2hiyxz+opySnlngKqNl04R3C4xBZoKiQkl/t98P9ei gqzPG1r/42jvF2quv00T/dBEO8iHPrIHBHWBCcN1HRDWqjVJvo6X6FIzfBIXdD784Z stNG69na6knFQ7aGvZBtZc8nu4F6ErqBm0A3TBnJ+4WtsWWbwCXEAwA8k8iOBnzgHa xCj+xjnlBuN7w== Original-Received: from alfajor (76-10-182-85.dsl.teksavvy.com [76.10.182.85]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 439FD12022C; Tue, 2 Feb 2021 09:37:41 -0500 (EST) In-Reply-To: <4ab742d461a50a1b9a0debba781a18ad@finder.org> (Jared Finder's message of "Tue, 02 Feb 2021 00:24:27 -0800") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham 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:263717 Archived-At: >> LGTM, but it would be good to improve the code so it determine this set >> of events automatically, e.g. by looking up local-map or something. > > I just went ahead and did a cleanup of the logic around here. Now there's > a keymap for all the navigation commands. Also a simple cache of all help > characters. Updated patch attached. LGTM. >>> Subject: [PATCH 3/4] Support 'mouse-autoselect-window' for GPM and xterm >>> mouse >> I think this should be consolidated with the *very* similar code in >> `src/msdos.c` and `src/w32inevt.c`. >> [ Ideally it should also be consolidated with the >> `Vmouse_autoselect_window` >> support in `src/xterm.c`, `src/nsterm.m`, and `src/w32term.c`. ] > > I completely agree. However, I don't have access to any of those platforms > to test against, so I do not feel comfortable making any changes. > Instead I added a fixme to all the different locations handling mouse > movement. Updated patch attached. I thought the parts in `src/msdos.c` and `src/w32inevt.c` were sufficiently similar that the change can be done without much risk of introducing a regression. >> [ Oh ... how I hate that echo area code. ] >> I think this needs a reproducible test case, ideally one we can run in >> batch as part of our test suite. > > I can do this, but I'm not sure what is the right way to test here. > Best I can see is to use current-message to read the current message string, > set unread-command-events to simulate key presses, and then call > read-key-sequence with a timeotu (like how read-key works). Does this > sound right? It does sound right, but I wouldn't be surprised if you encounter some difficulty because the code behaves differently in batch mode or because that message somehow gets erased just before your Elisp code gets to run. We don't yet have much experience testing these "interactive" aspects of Emacs, so it still frequently requires further changes to the code to make such testing possible. That's another reason it'd be good to have a test case here (it's a good opportunity to improve our testing facilities). >> Also, I'm curious about a few things: >> - How do we know that the echo area was cleared by calls to `read_char`? >> [ Do we even know for sure that `read_char` always clears it? ] > > read_char clears the echo area by calling "clear_message (1, 0)" if it > encounters any event other than help-echo, switch-frame, or select-window in > normal flow. See the comment "Now wipe the echo area, except for" in > read_char. > >> - How do we know that this extra line has the effect of restoring it to >> its pristine state? > > Isn't that what echo_area_buffer[1] is for? I have the impression that a whole lot of code can run between the `clear_message` and your code, so I don't immediately see why we can be sure that `echo_area_buffer[1]` indeed always contains the thing before the `clear_message`. And if it doesn't, then maybe we shouldn't try to revert the echo message. >> I think I'd like it better if we could make those things clear in >> the code. E.g. by having the "code that clears" set some variable >> indicating that it's indeed been cleared and maybe also how it's been >> cleared, and which we can then use here. >> Or alternatively, change the "code that clears" so that it doesn't >> actually clear when called from `read_key_sequence` and let >> `read_key_sequence` take care of clearing the echo area once it has >> *really* read some input? > > I don't think these are feasible as read_char's modifications of the echo > area can be dependent on waiting for user input. Specifically, it echos the > dash (via echo_dash) while waiting for input after an idle timer activates. > Pulling out read_char's existing code around idle timers to control all this > will be a beast to pull out. Additionally, I don't see how > read_key_sequence could know any better what to do as the translation maps > are just translating individual character events that if typed slowly > *should* be echoed. I agree it doesn't seem easy, but in my experience "do and later undo" sooner or later leads to extra difficulties so I tend to prefer "delay the do until we're sure we want to perform it". Stefan