bug#41420: 26.3; Terminal to 9 columns if other buffer killed (emacs daemon)

[K. Jansma]

When using Emacs with e.g. EXWM, it may happen that a terminal buffer resets 
the number of columns to 9 if another buffer is killed.
This is not an issue with EXWM, as the following reproduction scenarios shows:

1.    Go to an unused tty and run "emacs --fg-daemon -Q"

2.    go to another tty and run "emacsclient -c"

3.    Make sure the current frame has only one window C-x 0

4.    open terminal buffer M-x ansi-term

5.    switch to *scratch* C-x b *scratch* (since there is only one window, the 
terminal will now be hidden)

6.    kill the scratch buffer C-x k *scratch*

7.    You will see the terminal buffer again, but it wrapped all lines to 9 
columns max, despite the buffer covering the whole frame (there are no other 
windows) and there is no user-friendly (AFAIK) way to reset it to use the full 
buffer width

When not running Emacs as daemon, this does not happen.

Note that some users suggest never killing *scratch*, but AFAIK this is the 
only reliable way I'm currently aware of, to reproduce this issue. Under normal 
usage circumstances, it is not limited to killing *scratch*...


Another user who helped out in reproducing this issue [1] writes:

"When you run Emacs as a daemon it creates a hidden frame, and by default that 
frame will be 'displaying' the *scratch* buffer. (In a non-default invocation, 
it might be displaying something else.) When you kill the buffer which was 
displayed by the hidden frame, it means the hidden frame is now displaying 
something else. If that something else is your terminal buffer (probably the 
case if that was the most recent other buffer used) then you run headlong into 
the problem I described earlier.

Please M-x report-emacs-bug and include all the details I've mentioned here. I 
think the hidden frame created by the daemon should be displaying a 
special-purpose hidden buffer, so that you can't (easily) accidentally cause 
that frame to display anything else. Or perhaps killing any buffer displayed in 
the hidden frame could cause Emacs to immediately create a new hidden buffer to 
display in its place. Or if it's workable, a way to have that frame displaying 
no buffers at all might be cleaner.

term.el can probably work around this, but I think the source of the issue is 
so obscure that it makes all kinds of sense to address it generally, so that 
similar issues aren't caused for other libraries."


References:
[1] 
https://www.reddit.com/r/emacs/comments/gm1d8y/please_help_me_fix_this_bug_with_terminal_buffers/