bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#62575: 29.0.60; Tabs are not showing the right names of the buffers


From: Claudio Grondi
Subject: bug#62575: 29.0.60; Tabs are not showing the right names of the buffers
Date: Sat, 1 Apr 2023 14:28:14 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2


Along with this I have also noticed following problem:

1. ~ $ emacs -Q
2. Menu -> Options -> Show/Hide -> Tab Bar (gives Tab *scratch*)
3. resize the Emacs window to a small one, but large enough to show some Tab 
labels
3. 1x click on rightmost * in the Tab Bar to create a new Tab

The bug: No new Tab will be created and the minibuf and *Messages* show:

  split-window: Window #<window 3 on *Messages*> too small for splitting

Is it worth a new bug number?


On 4/1/23 13:38, Ruijie Yu wrote:

Claudio Grondi <claudio.grondi@freenet.de> writes:

Below the steps required to reproduce the bug:

1. ~ $ emacs -Q
2. Menu -> Options -> Show/Hide -> Tab Bar (gives Tab *scratch*)
3. 1x click on rightmost * in the Tab Bar to create a new Tab (gives 2x
*scratch* Tabs)
4. With the rightmost (second) Tab open ~/.emacs (gives 1x *scratch* and 1x
.emacs Tabs)
5. 2x click on rightmost * in the Tab Bar to create twp new Tabs (gives 1x
*scratch* and 3x .emacs Tabs)
6. with rightmost Tab active kill the .emacs buffer [C-x k] (the Tabs label
turns  to *scratch the other two Tabs labeled .emacs keep their labels, so there
are 1x *scratch*, 2x .emacs, 1x *scratch* Tabs)
7. *click the second Tab labeled* .emacs' (result: the label of the Tab turns to
*Messages*. the Tab Bar shows *scratch* *Messages* .emacs *scratch* )

The bug: the third Tab still keeps its  .emacs  label, the click on the second
Tab labeled  .emacs  did not show the .emacs file, but the buffer *Messages*.
Can reproduce in 30 (db7e95531ac36ae842787b6c5f2859d0642c78cc) and 28.2
(tagged) -- so even if this is a regression, it would not be a recent
one.

Essentially, the reported bug can be summarized as: the tab names on a
tab bar do not respond to situations where a buffer has been deleted.

In addition, I noticed that this behavior extends to renaming a buffer
as well (tried it in 30, not in 28.2).  The reproducer is to replace (6)
above with the following, and observe that the other tabs do not update
their names until you click on them.

     C-x x r hello RET






reply via email to

[Prev in Thread] Current Thread [Next in Thread]