From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#68235: 29.1.90; Switching tabs stops following process output in selected window Date: Mon, 15 Jan 2024 19:53:13 +0200 Organization: LINKOV.NET Message-ID: <865xzuvdgu.fsf@mail.linkov.net> 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> <92085305-caad-4bb6-ac55-a81415404a26@gmx.at> <86v885je23.fsf@mail.linkov.net> <868r4ymn7x.fsf@mail.linkov.net> <86h6jlqh2i.fsf@mail.linkov.net> <5e438b04-6fb7-4114-a5a8-61db9809b297@gmx.at> <86cyu7m4kc.fsf@mail.linkov.net> <2f80855c-3bf9-4973-a484-059cdef3b8c7@gmx.at> <669371d8-7c65-4c5f-99a9-0d8298808d23@gmx.at> <86cyu5cc0p.fsf@mail.linkov.net> <868r4reoh3.fsf@mail.linkov.net> <0634c46f-db93-4492-be69-5ac6ca0102a8@gmx.at> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21010"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) Cc: daniel.c.mccarthy@gmail.com, Eli Zaretskii , 68235@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jan 15 18:58:21 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 1rPRE3-0005Ie-Ic for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 15 Jan 2024 18:58:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rPRDo-0000rL-43; Mon, 15 Jan 2024 12:58:04 -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 1rPRDn-0000qr-8R for bug-gnu-emacs@gnu.org; Mon, 15 Jan 2024 12:58:03 -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 1rPRDn-0002l5-0T for bug-gnu-emacs@gnu.org; Mon, 15 Jan 2024 12:58:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rPRDm-00052U-SU for bug-gnu-emacs@gnu.org; Mon, 15 Jan 2024 12:58:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 15 Jan 2024 17:58: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.170534144119301 (code B ref 68235); Mon, 15 Jan 2024 17:58:02 +0000 Original-Received: (at 68235) by debbugs.gnu.org; 15 Jan 2024 17:57:21 +0000 Original-Received: from localhost ([127.0.0.1]:46800 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPRD7-00051F-AW for submit@debbugs.gnu.org; Mon, 15 Jan 2024 12:57:21 -0500 Original-Received: from relay9-d.mail.gandi.net ([217.70.183.199]:35759) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPRD5-00050p-76 for 68235@debbugs.gnu.org; Mon, 15 Jan 2024 12:57:19 -0500 Original-Received: by mail.gandi.net (Postfix) with ESMTPSA id 09459FF805; Mon, 15 Jan 2024 17:57:11 +0000 (UTC) In-Reply-To: <0634c46f-db93-4492-be69-5ac6ca0102a8@gmx.at> (martin rudalics's message of "Mon, 15 Jan 2024 11:24:06 +0100") X-GND-Sasl: juri@linkov.net 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:278293 Archived-At: > /* Scan dead buffer windows. */ > for (; CONSP (dead_buffer_windows); > dead_buffer_windows = XCDR (dead_buffer_windows)) > { > window = XCAR (dead_buffer_windows); > if (WINDOW_LIVE_P (window) && !EQ (window, FRAME_ROOT_WINDOW (f))) > delete_deletable_window (window); > } > which will be a bit hairy to be on the safe side. This could not be > solved with a 'post-set-window-configuration-hook' because at that time > the window would have been deleted already. Maybe then at least would be possible to display a message that will list the names of dead buffers. That might help the users to restore the buffers killed accidentally. OTOH, this is not needed in case of using the tab-bar because before switching to the tab with the killed buffer, the name of the killed buffer is visible as the tab name. >> The same window parameter could be used in a window with >> a reverted dired buffer to move point to a previous file name. > > Finding the right place to do that within 'set-window-configuration' > might be non-trivial. Here using 'post-set-window-configuration-hook' > would be probably better. Or maybe instead of 'post-set-window-configuration-hook' it's easy to call a post-processing function after 'set-window-configuration'. BTW, there is another problem when the same buffer is displayed in two tabs/window-configurations. For example, in the first tab point is near the top of the buffer, and in the second tab point is near the bottom of the same buffer. The user edits the top of the buffer in the first tab and saves writable window states to the desktop. At this point, all positions saved in the second tab are wrong because writable window states save point instead of the marker. One workaround is before saving the desktop to revisit all tabs that will update points from markers in writable window states. But this won't help too much because there is still the same problem after restoring the desktop. When the desktop is restored with right positions of all points, and the user edits the top of the buffer in the first tab before visiting the second tab, then after switching to the second tab point will be at wrong position, because the tab is restored from window states. Here the same workaround is possible: to revisit all tabs after restoring the desktop, that will create window configurations from window states. But automatically revisiting all tabs is too harmful because some tabs might lost their names: when a buffer was killed, then the tab will be renamed to the name of the buffer that replaces the killed buffer, and the user loses the hint what buffer was displayed in the tab originally. To solve the problem of outdated points/markers in window states maybe in addition to point, window states could also store context strings like bookmark.el does? I don't know how reliable these bookmark contexts are.