From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal Date: Thu, 28 Mar 2024 08:11:15 +0200 Message-ID: <86v856hon0.fsf@gnu.org> References: Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29456"; mail-complaints-to="usenet@ciao.gmane.io" Cc: olaf.rogalsky@gmail.com, 69915@debbugs.gnu.org To: Jared Finder Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Mar 28 07:12:20 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1rpizr-0007SG-Lf for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 28 Mar 2024 07:12:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rpizb-0008In-Km; Thu, 28 Mar 2024 02:12:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rpiza-0008IL-PQ for bug-gnu-emacs@gnu.org; Thu, 28 Mar 2024 02:12:02 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rpiza-0007ty-Go for bug-gnu-emacs@gnu.org; Thu, 28 Mar 2024 02:12:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rpiza-0003k7-LJ for bug-gnu-emacs@gnu.org; Thu, 28 Mar 2024 02:12:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 28 Mar 2024 06:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69915 X-GNU-PR-Package: emacs Original-Received: via spool by 69915-submit@debbugs.gnu.org id=B69915.171160628914209 (code B ref 69915); Thu, 28 Mar 2024 06:12:02 +0000 Original-Received: (at 69915) by debbugs.gnu.org; 28 Mar 2024 06:11:29 +0000 Original-Received: from localhost ([127.0.0.1]:38802 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rpiz2-0003h7-NE for submit@debbugs.gnu.org; Thu, 28 Mar 2024 02:11:29 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48854) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rpiyy-0003gI-OE for 69915@debbugs.gnu.org; Thu, 28 Mar 2024 02:11:27 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rpiyr-0007qV-Jq; Thu, 28 Mar 2024 02:11:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=D0Uh5fxFNi6ZFpPJ9AoilEzLqYGoEYZx3rlMydyrn1k=; b=Dx5OdjQ+GQCp Pnt89qE/UzR9dC+TsNwe9+foYBSlQfUZ+bTDWGYRMJ7Bb3PH0w4QewOiC6YIpygIVhdgRvBPkTAC/ qKirKMs6yEl5bIY41uX8ORSk6mGEwAmVOA1WbnziIW7QEYozD7I1+Cro7DnyZO7cU9+Vqf7fo5IOD w2oPj5hxbXbDkb1uGLKvGs97lEVH0BcCYcPJONqoawQHapjLxwo0FERrxXRSo/EIQEZtm3edYM4Fq 631A80vSoKLr5WMZAPdT6jVa5id5RZKCbubkurpG3X5UMPf51sX5YGLcyNk7rkjUs9yhe3nzyG2cN rcOChn+5OEOF1Pybq9Ja4g==; In-Reply-To: (message from Jared Finder on Wed, 27 Mar 2024 14:47:27 -0700) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:282175 Archived-At: > Date: Wed, 27 Mar 2024 14:47:27 -0700 > From: Jared Finder > Cc: eliz@gnu.org, 69915@debbugs.gnu.org > > > On the other hand, looking at msdos.c, there is no test against > > the minibuffer. I believed, that the selection of the minibuffer > > is taken care of at +10638 of window.el. In my tests the patch > > behaves exactly like the documentation, quote: "Mouse > > auto-selection selects the minibuffer window only if it is active, > > and never deselects the active minibuffer window." I added the > > test, but commented it out. > > I'm not sure what the right way to proceed here is then. Eli, can you > give advice? > > Looking at different OS files that handle mouse_autoselect_window, I see > the following state for checks if the selected window is a minibuffer > with MINI_WINDOW_P: > > pgtkterm.c: checks > w32term.c: does NOT check > w32inevt.c: does NOT check > nsterm.m: checks > xterm.c: checks > msdos.c: does NOT check > haikuterm.c: checks > androidterm.c: checks > term.c: no support for mouse-autoselect-window. :( > > My gut is to assume that the X and GTK behavior is most likely to be > better tested and more correct, but I defer to Eli here. I tend to agree. But, just to be sure, can you or Olaf describe the exact issue and how it could happen, and perhaps show a recipe to try reproducing it? I'd like to take a closer look at the relevant code. > > I also commented out a condition, which ensures that the selection of a > > window can only occur, if the mouse is in the text area of the window. > > This matches the following sentence of the documentation: > > "In either case, the mouse pointer must enter the text area of a window > > in order to trigger its selection." > > But I found no situation, where it did matter and msdos.c didn't have > > that test, either. WDYT? > > I think the documentation is incorrect and this commented out case > should be removed. Local testing on PGTK and Mac shows that the mouse > pointer can be over the window dividers, widget scroll bars, or fringes > and still have autoselect behavior activate. Is this at all relevant for TTY frames? Everything is "text area" on TTY frames, right? If not, what are the use cases where the mouse would be "not in the text area" on a TTY frame, in the context of auto-selecting a window? > >> > + (progn > >> > + (put 'select-window 'event-kind 'switch-frame) > >> > + (setf (car event) 'select-window) > >> > + vec) > >> > I think this should be an event that's just select-window and the window, to line up with what the select-window event looks like on other platforms (I tested PGTK and Windows terminal). You can verify this by running M-x trace-function RET handle-select-window RET. > >> > That would instead be something like: > >> > (progn > >> (put 'select-window 'event-kind 'switch-frame) > >> (vector `(select-window (,ev-window))) > > > > I can't find the documentation of the format of the select-window > > event. Maybe its a good idea to add it. > > Agreed. I think it should be added to Focus Events in commands.texi. I agree. > > Please find below the next iteration of the patch. > > Assuming above comments are addressed, this looks good to me. I imagine > there will be minor comment reformatting to avoid going beyond 80 > columns. Thanks, please post the final version after these minor changes for review. Thanks.