[shell] Fix shell-pop renaming the wrong buffer for eat

[bcc32]

Fix #16794.

[bcc32]

eat uses pop-to-buffer-same-window to display the newly-created eat-mode buffer after the command terminates, but does not leave the buffer current at the end. shell-pop assumes that the function passed in leaves the new buffer current, so we have to reconcile these by just using set-buffer.

Perhaps it would be better to advocate for eat, vterm, etc. support upstream in shell-pop?

[fnussbaum]

eat uses pop-to-buffer-same-window to display the newly-created eat-mode buffer after the command terminates, but does not leave the buffer current at the end.

This could also be considered a bug in eat, see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=69259#31. Perhaps it should also be fixed there? I think it might still be good to merge this in the meantime.

Perhaps it would be better to advocate for eat, vterm, etc. support upstream in shell-pop?

I think this is a good idea. (Additionally, it would be nice for shell-pop to switch to display-buffer as suggested in kyagi/shell-pop-el#61, but this is not a tiny change.)

[fnussbaum]

This could also be considered a bug in eat, see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=69259#31.

The elisp manual at least discourages this:

"When an editing command returns to the editor command loop, Emacs
automatically calls ‘set-buffer’ on the buffer shown in the selected
window (*note Selecting Windows::). This is to prevent confusion: it
ensures that the buffer that the cursor is in, when Emacs reads a
command, is the buffer to which that command applies (*note Command
Loop::). Thus, you should not use ‘set-buffer’ to switch visibly to a
different buffer; for that, use the functions described in *note
Switching Buffers::.

When writing a Lisp function, do not rely on this behavior of the
command loop to restore the current buffer after an operation. Editing
commands can also be called as Lisp functions by other programs, not
just from the command loop; it is convenient for the caller if the
subroutine does not change which buffer is current (unless, of course,
that is the subroutine’s purpose)." (Elisp manual, chapter 28.2 Current Buffer)

[bcc32]

Good idea, fixing upstream in eat at https://codeberg.org/akib/emacs-eat/pulls/193.

[ryanprior]

@bcc32 thank you! I've been trying on and off to fix this since I introduced eat to the shell layer but hadn't nailed down what the problem was yet.