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

["K. Jansma" via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

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/