GNU bug report logs - #71779
30.0.60; tab-bar-select-restore-windows: docstring vs default value

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 71779 in the body.
You can then email your comments to 71779 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.60; tab-bar-select-restore-windows: docstring vs default value
Date: Wed, 26 Jun 2024 08:44:10 +0200

[Message part 1 (text/plain, inline)]

Heya!

Intrigued by tab-bar-select-restore-windows's docstring:

> Function called when selecting a tab to handle windows whose buffer was killed.
> When a tab-bar tab displays a window whose buffer was killed since
> this tab was last selected, this function determines what to do with
> that window.  By default, either a random buffer is displayed instead of
                ^^^^^^^^^^
> the killed buffer, or the window gets deleted.  However, with the help
> of ‘window-restore-killed-buffer-windows’ it’s possible to handle such
> situations better by displaying an information about the killed buffer.

Over here, 'emacs -Q' suggests that _by default_, this option is set to
the eponymous symbol 'tab-bar-select-restore-windows'.  So the default
behaviour that I observe, when coming back to a tab that used to show a
killed buffer, is a special-mode buffer named " *Old buffer foo*" saying
"This window displayed the buffer ‘foo’."

Based on the NEWS entry, I guess the effective default behaviour is the
one intended?  In which case, I'm attaching a suggested rewording of the
docstring, based on understanding gleaned from cross-referencing the
NEWS entry, the docstrings for set-window-configuration,
window-restore-killed-buffer-windows, the corresponding manual entries,
and the source for set-window-configuration.

I am not 100% sure I succeeded in capturing the state of things, so feel
free to dismiss the patch; my main goal was to make it easier for Past
Me to get an answer to the question: "How do I get the previous
behaviour back"?

(Rationale FWIW: IME killing buffers is deliberate, so the placeholder
buffer feels redundant, i.e. it brings no information; if I am
displeased with whatever random buffer was picked to show in that
window, I can just switch to another buffer or delete the window)

[Message part 2 (text/x-diff, inline)]

diff --git a/lisp/tab-bar.el b/lisp/tab-bar.el
index 3401b796cac..58d2ef650a1 100644
--- a/lisp/tab-bar.el
+++ b/lisp/tab-bar.el
@@ -1456,10 +1456,18 @@ tab-bar-select-restore-windows
   "Function called when selecting a tab to handle windows whose buffer was killed.
 When a tab-bar tab displays a window whose buffer was killed since
 this tab was last selected, this function determines what to do with
-that window.  By default, either a random buffer is displayed instead of
-the killed buffer, or the window gets deleted.  However, with the help
-of `window-restore-killed-buffer-windows' it's possible to handle such
-situations better by displaying an information about the killed buffer."
+that window.  By default, a placeholder buffer is displayed in that
+window to give the user information about the killed buffer; this
+option can also be set to:
+
+ * nil:        no special handling; `set-window-configuration' will
+               decide what to do with the window, e.g. make it display
+               another buffer;
+
+ * a function: display another buffer in that window, and pass that
+               buffer to the function.  See
+               `window-restore-killed-buffer-windows' for the calling
+               convention."
   :type '(choice (const :tag "No special handling" nil)
                  (const :tag "Show placeholder buffers"
                         tab-bar-select-restore-windows)

Message #8 received at 71779 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
Cc: 71779 <at> debbugs.gnu.org
Subject: Re: bug#71779: 30.0.60; tab-bar-select-restore-windows: docstring
 vs default value
Date: Thu, 27 Jun 2024 19:59:20 +0300

close 71779 30.0.60
thanks

> I am not 100% sure I succeeded in capturing the state of things, so feel
> free to dismiss the patch; my main goal was to make it easier for Past
> Me to get an answer to the question: "How do I get the previous
> behaviour back"?

Thanks, I adapted your suggestion for the docstring.

> (Rationale FWIW: IME killing buffers is deliberate, so the placeholder
> buffer feels redundant, i.e. it brings no information; if I am
> displeased with whatever random buffer was picked to show in that
> window, I can just switch to another buffer or delete the window)

Actually, it's not about displeasing, it's about confusion.
For example, a user has a tab with the name "NEWS", switches
to another tab and kills the buffer, then quits Emacs,
and the next day opens the tab "NEWS", and it displays
a random buffer, e.g. "TODO".  So the user asks: "Why?"
With this option the answer in the same window.

Message #13 received at 71779 <at> debbugs.gnu.org (full text, mbox):

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: 71779 <at> debbugs.gnu.org
Subject: Re: bug#71779: 30.0.60; tab-bar-select-restore-windows: docstring
 vs default value
Date: Sat, 29 Jun 2024 11:13:22 +0200

Juri Linkov <juri <at> linkov.net> writes:

>> I am not 100% sure I succeeded in capturing the state of things, so feel
>> free to dismiss the patch; my main goal was to make it easier for Past
>> Me to get an answer to the question: "How do I get the previous
>> behaviour back"?
>
> Thanks, I adapted your suggestion for the docstring.

Looks good to me, thanks 🙏

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.