From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#68235: 29.1.90; Switching tabs stops following process output in selected window Date: Sun, 7 Jan 2024 15:54:44 +0100 Message-ID: <92085305-caad-4bb6-ac55-a81415404a26@gmx.at> References: <83frzdy6if.fsf@gnu.org> <86edexnmv8.fsf@mail.linkov.net> <83mstlvvkj.fsf@gnu.org> <34a872a9-07b2-4671-837f-f8d98b37420d@gmx.at> <867ckmxto2.fsf@mail.linkov.net> Reply-To: martin rudalics Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2778"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: daniel.c.mccarthy@gmail.com, Eli Zaretskii , 68235@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jan 07 15:56:12 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 1rMUZP-0000Ws-Vc for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 07 Jan 2024 15:56:12 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rMUZH-000159-Pi; Sun, 07 Jan 2024 09:56:03 -0500 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 1rMUZB-00014b-6f for bug-gnu-emacs@gnu.org; Sun, 07 Jan 2024 09:55:58 -0500 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 1rMUZA-000394-V7 for bug-gnu-emacs@gnu.org; Sun, 07 Jan 2024 09:55:56 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rMUZG-0002G3-H0 for bug-gnu-emacs@gnu.org; Sun, 07 Jan 2024 09:56:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 07 Jan 2024 14:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 68235 X-GNU-PR-Package: emacs Original-Received: via spool by 68235-submit@debbugs.gnu.org id=B68235.17046393027689 (code B ref 68235); Sun, 07 Jan 2024 14:56:02 +0000 Original-Received: (at 68235) by debbugs.gnu.org; 7 Jan 2024 14:55:02 +0000 Original-Received: from localhost ([127.0.0.1]:60881 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMUYH-0001zr-MF for submit@debbugs.gnu.org; Sun, 07 Jan 2024 09:55:02 -0500 Original-Received: from mout.gmx.net ([212.227.17.20]:56327) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMUYE-0001zP-P4 for 68235@debbugs.gnu.org; Sun, 07 Jan 2024 09:55:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.at; s=s31663417; t=1704639285; x=1705244085; i=rudalics@gmx.at; bh=bi6leWoZ8y+nHHQf9w13C9rWvsp/U3W1KtLh8awU3uY=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From: In-Reply-To; b=svrEXHO2XlUnIQyB9KPKrDOLUyrLVjC4IbFgrrM8PddHw9nwwscfmkbcaVdckunR m7ZPdqj71PdKgvw9UeFmckwwnylnvgYvXwGtLinb4kxJ7Nl/TIpW7Xvt1ueUn2ZME TAhGXq3KhJmSiPDAgMqpsWuW2d4EHxWDeHPtXklpAFXcHMfru9NlDDpor/z8zPXab A+EMoNxsYIAH0wiB0RS6se60aNNxoT7rDMyZWhJFd99RAbdVmqzFtThJcmJU5bfBH VC7HN/xanrW/Lvls7CBRNQGyLmXQ7U2K6eZ8BLJbOH86ArLt5tQdUG8bCIL+WNlt/ f0dn9pinsGib9kVWeA== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from [192.168.31.113] ([213.142.97.200]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MYNNy-1rhxId0qNG-00VQ0J; Sun, 07 Jan 2024 15:54:45 +0100 Content-Language: en-US In-Reply-To: <867ckmxto2.fsf@mail.linkov.net> X-Provags-ID: V03:K1:s/2+KgFCL47mQSb8pXX5epCJlLynACFeXRt/kNfICuFkF4XDDWV XEmVCrug19Jf89HVhqo/4hxhgI0iPrNf4kbrGJHKyFyn0d1Zkz/guVwdBHKOizJM/0cLF2p bERPuvybxRN1Hdy6RVlphf58yFlflTVUc79W7PMrQa+1ukO1XG78xgovxiBUDNkaZmV3LS3 jOkk95BeCvPxOLxJrsl8w== UI-OutboundReport: notjunk:1;M01:P0:hH4aXw1oqBo=;DAbETjVKKjh/c5C3UliPdSMObbq eFsdp2F6WQm/TapdrtjSshrgLUyC7rjwc94mpkwJVT8Lht00/hec3aP2TA5TekjFpHdz1/WBH cFh3eDdl+JOGPeht8oyyAfmqzK6EHOvO27Mxs58s6C0Dw2rALUhJaBCSHxG9enaGj8cX1oO2v WibCFXRWR3NgU7GSgKNutZ4ohLxYUXG34mQLs+pahONQop8QetRpkalr5Xqk/WQ3quXxFlQSo oQ1nIOLH1lzw1w2p+K6KoVbP3jMSOYeyzSmrE5bogiX0oQg1zHCeilCORzWHGgH4Lsejaqg6y FUv1+Lo00WmQQhI69B72nxCIf/jGuRFipb3yewl1Unb40K/YSpktidWY7ZgnmBngDZmnIu/tV opbLGQLaJSoYVI6AjslSznvP/oUqNlhReDELbBe7GhzOYV2Rw0OioPQX6XdyPZ2ew4ZCe/f/a Awg7DrguV+fikQhglM52jB2Oha/ver13ajaVWpDHiFR7uaiOmNWr1IQJ3AtIjxIUwSPmtcZzz 8A0FHWZ9F0OtyJUEJkA0l9KvvqldBFxLWW10morbmJ7HXTedbBS9xtDS//1qXHJJLdwgljf/b /v5uLcrqD4KN+Dz73CZJyJxt9cFIzQonUnDpU+astq+yEwuGH2oW9+9B+/fxlPGeoRnmULoqo S0q7H8zBKQ4SEC4d09zmNAUr5PXsWYKDo/TOrYFttZCM/C4WdwVX84IwSJl4f+//3wVEgx7Wr U7Zy7zvRu07/6NLMRuSE1oe1LmI6w6jD2XA8vbIPU9iRC5n7ZqcQhgbH4Qe5Vyn8qFnetRpx 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:277502 Archived-At: > window-point-insertion-type is nil by default, but I'd definitely want > point to follow the output, that means not using the snippet above. But 'window-point-insertion-type' is buffer-locally t in all sorts of compilation buffers and that is the subject of this bug report. Right? > OTOH, this snippet can't be removed because it supports tab-local point. > For example, open the same buffer in two tabs and move point to another > place. Like with window-point, the position of point in tabs should be > preserved as well. So probably we need to add special-casing for comint > buffers to follow the output. And I meant to use the buffer-local value of 'window-point-insertion-type' as insertion type for 'wc-point'. > But could you explain why such special-casing is not needed for > non-selected windows? How set-window-configuration does the right > thing for points in non-selected windows to follow the output? > Maybe it's possible to do the same with point in the selected window? For an unselected window, 'set-window-configuration' uses that window's point marker from the saved configuration and that one should follow inserted text according to the value of 'window-point-insertion-type' in that window's buffer. For the selected window, that window's buffer's point is "usually" unchanged from where it was just before restoring the configuration. In either case I doubt that the 'set-window-configuration' code does anything wrong here. IIRC there were problems in the dired buffer reverting code, namely that it did not preserve the position of point reasonably and you tried to handle that via 'wc-point'. martin