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: Tue, 16 Jan 2024 11:19:28 +0100 Message-ID: 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> <865xzuvdgu.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="19334"; 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 Tue Jan 16 11:20:27 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 1rPgYV-0004m5-Gy for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 16 Jan 2024 11:20:27 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rPgY9-0004U3-Nd; Tue, 16 Jan 2024 05:20: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 1rPgY6-0004TR-D7 for bug-gnu-emacs@gnu.org; Tue, 16 Jan 2024 05:20: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 1rPgY6-0001yj-1l for bug-gnu-emacs@gnu.org; Tue, 16 Jan 2024 05:20:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rPgY6-0006b0-9n for bug-gnu-emacs@gnu.org; Tue, 16 Jan 2024 05:20: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: Tue, 16 Jan 2024 10:20: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.170540037925287 (code B ref 68235); Tue, 16 Jan 2024 10:20:02 +0000 Original-Received: (at 68235) by debbugs.gnu.org; 16 Jan 2024 10:19:39 +0000 Original-Received: from localhost ([127.0.0.1]:47822 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPgXj-0006Zn-8R for submit@debbugs.gnu.org; Tue, 16 Jan 2024 05:19:39 -0500 Original-Received: from mout.gmx.net ([212.227.17.21]:36583) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPgXg-0006ZR-Ns for 68235@debbugs.gnu.org; Tue, 16 Jan 2024 05:19:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.at; s=s31663417; t=1705400369; x=1706005169; i=rudalics@gmx.at; bh=sDprlDR3/oT5J7QUq9eJPw//95R8sDlAX6u+NgfYQqo=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From: In-Reply-To; b=BnwKBmjNdYeaxopKiPGXwDlWyEa/iGam2WBLA+901FaDynlaWu0QbjHNE8IS+RX2 tFvrmGd+LBJasYuNeAAhrkkxLkm3MtWgLbUWILF8oH/AHTfShhaqOEngubvp+84B2 RTg/JI9HC46hwSiDNpqWYHivYkeQtT+yPnm9t+I4jtWqp2K2A0BTLR+RqgnEsQfiw mpZ/EtERGY4Qsp5AvHCQP/S8KlRCaWJpkmdNdoEhJ99YcS/qKV1xgKkvFWGOy/ID/ MrR0gafOeIBO1eifJDQrsDenKI//+Jco1nu93vu8qXwsLHudrATHc/bb2msVZnSFX wP4pMsN/Nl9hLYpWdw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from [192.168.31.113] ([213.142.97.29]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MSKy8-1radqL0mi0-00Sfa0; Tue, 16 Jan 2024 11:19:29 +0100 Content-Language: en-US In-Reply-To: <865xzuvdgu.fsf@mail.linkov.net> X-Provags-ID: V03:K1:wxVIPlnxnw0kxf9jR9ewuYftIGfSsmjPWm62/F5MgQ5kvcSQLeP GsVI940e04zmhVLsuvK0YRJS6sfI2MZIqIR+EFJ+Z/Cx6DMlkox2u6wjrxX5MLuFht5owVa mViRT/GVpDz9GL81f7o9LpPaDhgOMthLxA88mD+T+PfXLJnHL1ubHp/eeOxcEg6sEr4lfb4 oxlFAbKg3f//bC1DcUaNg== UI-OutboundReport: notjunk:1;M01:P0:7e4V52S3f+M=;1dSQ2+u9j+PwrgaUTDAZ1IGFMac IEg52tGb3nC8xT/Mw6Xo6b/7EuAAk2qhOW57RmVGsL1y00s/b+O7a94VgabC8XIBjzeSB4UeZ kdbmHsb6tuQFCiopiNxHoclocanvPhExei8DbEhU5ZKjrPiCcpW/I4nkB7rBSvA1QAIfYVWX2 fFREZ+O/dBCbMHIKttbQqtVJOjcqTmRc5L7dmt2WAhKLgIJNE3+W+V7tdUKtXEFyARPnT/4rM 1BdQ+fd7k0VY7kk9SfqICYKrExTjame+0/ua/VZavlNQGUS8XhIpl/+hONZQcoso4Qg4iArkQ KF27Pc4Fi7u90tP1TC3up5CywZPb0S/C0US7tT90oglMC90mWfhzfXVeyTgW0y4r+Bdl+qGOw 39GYrVMtcx6vW40bAWVfkthSGQkpoOBWstnmpV8piMoJiJdTDWwyybbgO8dB6qfCSgPUUmEch 1k4sy8q8VxgddlH47E7+p2snneRFjXNDLlt+7+At5ZJGbavHCdI+DerCpxJ2S71qb4orHvavW GtM9j5qUO0cJ6xwBBMS0y2BzJduWjHb47ibDhNZ++eDkonfBnLtkCej2PJAIx3MSP54C+fO9J /NrE7Kwgtm0AJNlXKSMmJkJMLnUZBiJp+LMkjd8x1hsATxp4MYh/EKZ3TTqOsQ1Ll1kw5MWEn SzulHIxOk0px/D6smfvC09PIFJ7eM5mFBPrz0h8DjzkivU2oa2XoFjr81lUNH9yLL6isjW+I0 zhQP1S84cWKJ6T/6v8eG8Uw+R0eROk/B1fCt/bWJvmv+hziI2C2hUp0MUFkQiiio0s4l/rm4 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:278327 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? > 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. 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? > 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. 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. > 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? > 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? > 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. > 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? > 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. martin