bug#63956: 29.0.91; tex-mode display problem in emacs-29

[Jeff Norden <norden.jeff@gmail.com>]

On Sun, Jun 11, 2023 at 1:22 AM Eli Zaretskii <eliz@gnu.org> wrote:
...
> No further comments, so I've now added a new defcustom, called
> display-tex-shell-buffer-action, and made its default value be
> display-buffer-in-previous-window.  With that, I'm closing this bug.

Eli: Sorry for the delay.  I started to compose this response
yesterday, but life intervened before I could finish and send it.
Adding a new defcustom would be fine as well.
---------------
I suggest just removing the actions from the two display-buffer calls
and the pop-top-buffer call in tex-mode.el.

I think this is definitely the right thing for the display-buffer
calls, which apply to the *tex-buffer* created by `tex-file', etc.
This buffer is very much like a *compilation* buffer.  In fact, you
can do much the same thing as tex-file using "M-x compile" by just
changing "make -k" to "tex foo.tex" in the minibuffer. However, a
*tex-shell* window works better for parsing errors, etc, since it is
set up for TeX.  In compile.el, display-buffer is actually called with
an action of:
   '(nil (allow-no-window . t))
but I have no idea why.  I can't think of a reason to run TeX on a
file and not display the *tex-shell* buffer.

The pop-to-buffer call only applies to a docview buffer created for
previewing a pdf.  This isn't a comint or shell window of any sort.
Opening in a new frame might make sense, but I wouldn't suggest
changing the behavior right now.
----
It was interesting to use tex-mode under 'emacs -Q', which I haven't
done for many years.  I've got a number of ideas for fixes and
improvements.  I'll try to write them up in a cogent way and post to
emacs-devel for discussion.  There is certainly nothing urgent enough
to consider for the (imminent?) emacs-29 release.
---------------
More generally: comint derived modes can be, and are, used for a
variety of purposes.  It seems that the intention of the new defcustom
introduced by Sam is that it should apply to ones that provide an
interactive shell-type buffer that is independent of other tasks.
I wonder if 'display-shell-buffer-action' might be a better name.
In any case, I think it would be good for the defcustom doc-string to
list the derived modes that use it, so that people would know just
what to expect if they customize it.  It might even make sense to
eventually use it for things like the pop-to-buffer call in
`scratch-buffer', since lisp-interaction is a shell in the general
sense.  Currently, scratch-buffer uses pop-to-buffer-same-window like
shell-mode previously did.

Thanks,
-Jeff