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

[Eli Zaretskii]

> From: Sam Steingold <sds@gnu.org>
> Date: Fri, 09 Jun 2023 16:00:56 -0400
> 
> here is what I see:
> 
> commit 18b680cfd177e877991be2bd70ead628bbdc0aa0
> Author: Sam Steingold <sds@gnu.org>
> Date:   2021-12-28 17:27:41 -0500
> 
>     Fix bug#52467 by adding a new custom variable 
> 'display-comint-buffer-action'
>     
>     * lisp/window.el (display-comint-buffer-action): New `defcustom`,
>     defaults to 'display-buffer-same-window' for backward compatibility.
>     * lisp/cmuscheme.el (run-scheme, switch-to-scheme): Pass
>     'display-comint-buffer-action' to 'pop-to-buffer' instead
>     of using 'pop-to-buffer-same-window'.
>     * lisp/eshell/eshell.el (eshell): Likewise.
>     * lisp/shell.el (shell): Likewise.
>     * lisp/org/ol-eshell.el (org-eshell-open): Likewise.
>     * lisp/progmodes/inf-lisp.el (inferior-lisp): Likewise.
>     * lisp/progmodes/project.el (project-shell, project-eshell): Likewise.
>     * lisp/textmodes/tex-mode.el (tex-display-shell, tex-compile-default)
>     (tex-recenter-output-buffer): Pass 'display-comint-buffer-action'
>     to 'pop-to-buffer'.
> 
> >> The commit is tagged with my correct gnu.org address.
> > It isn't see above.
> 
> I am confused.

I don't know why this happens, perhaps due to differences in Git
versions?  I'm guessing you have some non-trivial setup of your email
address for Git or something?  The @amazon.com address wasn't just
concocted by my Git client out of thin air, right?

I tried on 2 other systems.  One of them, with Git v2.34.1 reports
what you see; the other, with Git 2.17.1, reports what I see.

> >> Please only use sds@gnu.org for all communications.
> >
> > Sorry, I cannot afford proofreading every address I copy from the Git
> > logs.  I simply don't have that kind of time.
> 
> I am with you, but note that you risk getting your emails bouncing.

When it bounces, I will look for a different address, so this is fine.
But maybe you could make whatever email setup you have for Git so this
doesn't happen in the first place?

> > Are you sure you don't have any customizations that get in the way?
> 
> Yeah, looks like I do:
> --8<---------------cut here---------------start------------->8---
>  '(display-buffer-alist
>    '(("shell\\*" nil (inhibit-same-window . t))))
> --8<---------------cut here---------------end--------------->8---
> 
> When my change was discussed, I was told that adding a new custom
> variable was okay, but making it have non-trivial default is not.

This is fine, but making commands use the default value of this new
custom variable changes behavior, and at least for tex-buffer the
change is for the worse.

> Maybe `display-comint-buffer-action' should default to
> `display-buffer-in-previous-window'?

That works for me, but I think it's too late to change the default
now, 1.5 years after the defcustom was introduced.  (It could be a
good idea for master, perhaps.)  So at this point, on the release
branch, I'd like to fix only the specific problems we see, without
risking any unrelated breakage.  To understand how best to solve this,
I need you two (and anyone else who uses tex-mode) to look at the
other uses of this defcustom in tex-mode, and tell me whether any of
them also need fixing.  As I wrote in my original message:

> Jeff, would you please look at the 3 places in tex-mode where
> display-comint-buffer-action was added to calls to pop-to-buffer and
> display-buffer, and tell in which ones showing the buffer in the same
> window by default makes sense?  I don't myself use tex-mode, so it is
> hard for me to tell.  We could then discuss whether to remove the
> argument in some of the cases or make a tex-mode-specific user option
> to let users control that.  For example, in the specific case of
> tex-display-shell it sounds like just dropping the argument would be
> TRT, since all of its callers want to show the shell buffer, but not
> in the selected window.  What about the other two cases where this
> argument was added?

Would you two please help me understand how best to fix this
regression by providing the above information?  TIA.