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#33871: 27.0.50; Revert Dired window saved in window configuration Date: Sun, 24 Mar 2024 19:12:53 +0200 Organization: LINKOV.NET Message-ID: <86frwf8w4q.fsf@mail.linkov.net> References: <87bm59mglk.fsf@mail.linkov.net> <86sfsewvxr.fsf@mail.linkov.net> <9d741b43-e3bb-669b-b345-6b877c902b33@gmx.at> <86fsoaq4lo.fsf@mail.linkov.net> <86tucp7dbp.fsf@mail.linkov.net> <37e2129c-464f-7f0a-0870-f7360ca21dc3@gmx.at> <86zfw07tbw.fsf@mail.linkov.net> <96fd3170-e5d2-4d16-93ec-c6fff3efb787@gmx.at> <86wmr2w7to.fsf@mail.linkov.net> <3808f9f8-624a-449c-8572-085582395859@gmx.at> <86y1bffvya.fsf@mail.linkov.net> <8634skstio.fsf@mail.linkov.net> <86msqr79n8.fsf@mail.linkov.net> <532c59dc-59af-4454-b926-2f80fe711fe9@gmx.at> <86zfuq5jxj.fsf@mail.linkov.net> <5cf2b85e-9e24-4a7d-b175-ce140580df32@gmx.at> <86plvksv1e.fsf@mail.linkov.net> <578de52d-364b-4961-b4e2-7f91cdcaa0b9@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="8170"; 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: 33871@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Mar 24 18:22:31 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 1roRYE-0001uN-2D for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 24 Mar 2024 18:22:30 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1roRXA-0006rX-NX; Sun, 24 Mar 2024 13:21:24 -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 1roRX8-0006qv-52 for bug-gnu-emacs@gnu.org; Sun, 24 Mar 2024 13:21:22 -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 1roRX7-0000nR-T2 for bug-gnu-emacs@gnu.org; Sun, 24 Mar 2024 13:21:21 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1roRXm-0004uJ-Nu for bug-gnu-emacs@gnu.org; Sun, 24 Mar 2024 13:22:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 24 Mar 2024 17:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33871 X-GNU-PR-Package: emacs Original-Received: via spool by 33871-submit@debbugs.gnu.org id=B33871.171130089318727 (code B ref 33871); Sun, 24 Mar 2024 17:22:02 +0000 Original-Received: (at 33871) by debbugs.gnu.org; 24 Mar 2024 17:21:33 +0000 Original-Received: from localhost ([127.0.0.1]:45352 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1roRXI-0004ry-L8 for submit@debbugs.gnu.org; Sun, 24 Mar 2024 13:21:33 -0400 Original-Received: from relay3-d.mail.gandi.net ([217.70.183.195]:43785) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1roRXF-0004rJ-Lu for 33871@debbugs.gnu.org; Sun, 24 Mar 2024 13:21:30 -0400 Original-Received: by mail.gandi.net (Postfix) with ESMTPSA id C3FEE60004; Sun, 24 Mar 2024 17:20:40 +0000 (UTC) In-Reply-To: <578de52d-364b-4961-b4e2-7f91cdcaa0b9@gmx.at> (martin rudalics's message of "Sun, 24 Mar 2024 10:54:11 +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:282026 Archived-At: >> OTOH, tab-bar.el is preloaded as well, so no problem to leave this >> in tab-bar.el, since window.el is too large already. > > Then I would give them a 'tab-bar-' prefix. I agree that if they remain in tab-bar.el they should have a 'tab-bar-' prefix. But OTOH, such prefix doesn't look right to use for hooks in dired-mode, because this is a general window functionality, not directly related to tabs. Maybe still would be better to add this to window.el? Then to not change the size of window.el, we could remove some existing lines that don't belong to window.el. For example, these defcustoms have no place in window.el: (defcustom display-comint-buffer-action (defcustom display-tex-shell-buffer-action Ok, I will create a separate bug report to remove them. >>> Maybe 'window-restore-set-context' and 'window-restore-use-context' >>> would be more indicative names. >> >> The name 'window-restore-set-context' looks quite self-contradictory. >> If your intention was to use a unique prefix, then maybe we could use the >> prefix 'window-context' like in 'window-context-set', 'window-context-use'. > > I'd say the context of a window are the other windows of the same frame. This was meant to denote a context inside a window. Then maybe a better prefix would be 'window-point-context'? >>> Note that when a buffer is killed, the values of its local variables may >>> be lost. I don't know whether this is an issue here. Alternatively, we >>> could have 'set_window_buffer' set the 'context' window parameter from >>> the buffer-local value which would, however, mean that whenever one >>> changes the buffer-local value, one would have to simultaneously update >>> the parameters in all windows showing that buffer. Something that could >>> be done with the help of an advice, though... >> >> This doesn't look like an issue here because the context is stored >> in a window parameter. > > IIUC the context is stored but not the function to restore the position > from the context. Indeed, there was an idea to store a function that restores point, but this might be problematic when saving such a function to the desktop file. Therefore, the patch has two separate functions to save and restore context as mere strings and numbers. >> And when the buffer is killed, there is no need >> to restore a context in the killed buffer. > > If you don't intend to restore the context from the file the buffer was > visiting. Are you sure you don't want to do that? After the buffer was killed? This doesn't seems necessary. >> The format of the window parameter >> >> '(BUFFER-NAME . ((dired-filename . FILENAME))) >> >> uses BUFFER-NAME to check whether the buffer was killed, >> and when the current window's buffer doesn't match BUFFER-NAME, >> then do nothing. > > What do you do when you want to restore a configuration from a tab, that > configuration contains a window whose buffer was killed but whose file > still exists and you wanted to revisit that file in the window with its > previous point? Ignore any context for that window? I think such cases are very rare.