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: Tue, 16 Jan 2024 18:30:22 +0200 Organization: LINKOV.NET Message-ID: <86a5p5qv61.fsf@mail.linkov.net> References: <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> <865xzuvdgu.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18192"; 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 Tue Jan 16 17:44:59 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 1rPmYc-0004Ua-Qz for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 16 Jan 2024 17:44:58 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rPmXl-0001fa-22; Tue, 16 Jan 2024 11:44:05 -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 1rPmXi-0001aD-PL for bug-gnu-emacs@gnu.org; Tue, 16 Jan 2024 11:44:02 -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 1rPmXi-0005vm-FG for bug-gnu-emacs@gnu.org; Tue, 16 Jan 2024 11:44:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rPmXi-0000kb-TI for bug-gnu-emacs@gnu.org; Tue, 16 Jan 2024 11:44: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: Tue, 16 Jan 2024 16:44: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.17054233842772 (code B ref 68235); Tue, 16 Jan 2024 16:44:02 +0000 Original-Received: (at 68235) by debbugs.gnu.org; 16 Jan 2024 16:43:04 +0000 Original-Received: from localhost ([127.0.0.1]:49559 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPmWm-0000ie-5h for submit@debbugs.gnu.org; Tue, 16 Jan 2024 11:43:04 -0500 Original-Received: from relay4-d.mail.gandi.net ([2001:4b98:dc4:8::224]:33561) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPmWj-0000i7-Gv for 68235@debbugs.gnu.org; Tue, 16 Jan 2024 11:43:02 -0500 Original-Received: by mail.gandi.net (Postfix) with ESMTPSA id 07C1EE000B; Tue, 16 Jan 2024 16:42:53 +0000 (UTC) In-Reply-To: (martin rudalics's message of "Tue, 16 Jan 2024 11:19:28 +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:278346 Archived-At: >> 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. > > The name of a killed buffer is nil as long as the buffer object has not > been collected. But would buffer names be of great use anyway? Isn't it > the name of the file, the info node, or the directory name the buffer > was visiting that counts? The buffer name often has a hint about the file/directory name. >> 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. > > Does the tab-bar code store the buffer name separately? But again - > that name won't help you much anyway once the buffer was killed. By default the buffer name is stored as a tab name. And it helps to know the purpose of why that tab was created. When the buffer was killed in another tab, it helps to decide whether the tab that displayed the killed buffer should be closed as well. > Incidentally, the name of the file a killed buffer was visiting will be > available as long as the buffer object exists. Do you mean that? What would be more useful to keep for the killed buffer is the value of its revert-buffer-function. Often calling this function can reconstruct the buffer contents. >> Or maybe instead of 'post-set-window-configuration-hook' it's easy >> to call a post-processing function after 'set-window-configuration'. > > 'post-set-window-configuration-functions' that's what I meant earlier - > with the frame as argument. But if a buffer is dead now, this won't > help in neither regard. First and foremost, 'set-window-configuration' > must be able to deal with dead buffers in a safe fashion. We could, > optionally, display *scratch* in all windows that have a dead buffer now. Instead of *scratch*, is it possible to display some special buffer that will display the name of the killed buffer, and a button that runs its revert-buffer-function? > Still 'post-set-window-configuration-functions' (and also the > desktop routines) would have to know enough about how to restore the > earlier state. This is something only a buffer's major mode itself may > know. Or revert-buffer-function. >> 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. > > But 'window--state-get-1' does > > (let ((point (window-point window)) > > which should reliable give the value of point in window and then > > (point . ,(if writable > point > (with-current-buffer buffer > (copy-marker point > (buffer-local-value > 'window-point-insertion-type > buffer))))) > > 'window--state-put-2' OTOH does > > (set-window-point window (cdr (assq 'point state)))) > > Do you see the problem here? The problem is that for writable window states 'window--state-get-1' saves point as a number from 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. > > So IIUC you mean that restoring the desktop (writable) does things > differently than restoring tabs (non-writable)? Can you tell me more > precisely the order of desktop/tab-bar operations involved in that > scenario? The desktop saves writable window states with point as a number. Switching tabs uses window configurations with point as a marker. >> Here the same workaround is possible: to revisit all tabs after >> restoring the desktop, that will create window configurations >> from window states. > > I'd still have to understand: A non-writable state should behave like a > window configuration. A writable state should do the same but for using > numbers instead of markers for positions. Indeed. Only writable window states saved to the desktop. >> 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. > > Again I'm not sure how you would retrieve the name of a killed buffer. > What am I missing? Currently there is no solution to this problem. >> 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. > > It would help when the file a buffer is visiting was modified outside > Emacs. In all other cases, the stored point should suffice. The stored point is not sufficient when saved as a number to the desktop file.