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

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

[Jeff Norden]

I've been trying out the 2nd emacs-29 pretest.  It seems great.
I haven't needed to tweak a single line of my .emacs or any of the
custom files it loads (about 1200 lines in all).  The new
'with-restriction' feature may simplify a project that I've been
playing with for a while.

However, I have found a minor issue with a change made to tex-mode.
The simple calls to `display-buffer' in tex-mode.el have been replaced
with:
    (display-buffer tex-shell display-comint-buffer-action)
The default value for display-comint-buffer-action is set from
display-buffer--same-window-action.

As a result, the default behavior of `tex-buffer' or `tex-region' is
that the document you are editing *disappears*, and and the window it
was displayed in shows just the error messages (or lack thereof) from
running TeX.  You then need to switch back to the document's buffer to
continue editing.  This behavior makes no sense.  It would be
equivalent to running `compile' on a C file, and then only seeing the
output from make/gcc/etc, with the source code hidden.  The correct
behavior in both cases is to show the process output in a window
alongside the source.  Anyone who has been using tex-mode for years
would certainly find this new behavior disruptive, although it is
easily corrected.

I'm not sure if the `display-buffer' calls in tex-mode.el need to have
an action argument, but if they do, it should be similar to what is
used in compile.el.  I'll be the first to admit that I'm not
particularly well-versed in the current intricacies of buffer display
actions (nor do I have any real desire to become so :-).

Thanks,
-Jeff

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

[Eli Zaretskii]

> From: Jeff Norden <norden.jeff@gmail.com>
> Date: Wed, 7 Jun 2023 12:52:10 -0500
> 
> I've been trying out the 2nd emacs-29 pretest.  It seems great.
> I haven't needed to tweak a single line of my .emacs or any of the
> custom files it loads (about 1200 lines in all).  The new
> 'with-restriction' feature may simplify a project that I've been
> playing with for a while.
> 
> However, I have found a minor issue with a change made to tex-mode.
> The simple calls to `display-buffer' in tex-mode.el have been replaced
> with:
>     (display-buffer tex-shell display-comint-buffer-action)
> The default value for display-comint-buffer-action is set from
> display-buffer--same-window-action.
> 
> As a result, the default behavior of `tex-buffer' or `tex-region' is
> that the document you are editing *disappears*, and and the window it
> was displayed in shows just the error messages (or lack thereof) from
> running TeX.  You then need to switch back to the document's buffer to
> continue editing.  This behavior makes no sense.  It would be
> equivalent to running `compile' on a C file, and then only seeing the
> output from make/gcc/etc, with the source code hidden.  The correct
> behavior in both cases is to show the process output in a window
> alongside the source.  Anyone who has been using tex-mode for years
> would certainly find this new behavior disruptive, although it is
> easily corrected.
> 
> I'm not sure if the `display-buffer' calls in tex-mode.el need to have
> an action argument, but if they do, it should be similar to what is
> used in compile.el.  I'll be the first to admit that I'm not
> particularly well-versed in the current intricacies of buffer display
> actions (nor do I have any real desire to become so :-).

Adding Sam, who made these changes in tex-mode.el.  Sam, any comments?

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?

Thanks.

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

[Sam Steingold]

> * Eli Zaretskii <ryvm@tah.bet> [2023-06-08 12:15:49 +0300]:
>
>> From: Jeff Norden <norden.jeff@gmail.com>
>> Date: Wed, 7 Jun 2023 12:52:10 -0500
>>
>> I've been trying out the 2nd emacs-29 pretest.  It seems great.
>> I haven't needed to tweak a single line of my .emacs or any of the
>> custom files it loads (about 1200 lines in all).  The new
>> 'with-restriction' feature may simplify a project that I've been
>> playing with for a while.
>>
>> However, I have found a minor issue with a change made to tex-mode.
>> The simple calls to `display-buffer' in tex-mode.el have been replaced
>> with:
>>     (display-buffer tex-shell display-comint-buffer-action)
>> The default value for display-comint-buffer-action is set from
>> display-buffer--same-window-action.
>>
>> As a result, the default behavior of `tex-buffer' or `tex-region' is
>> that the document you are editing *disappears*, and and the window it
>> was displayed in shows just the error messages (or lack thereof) from
>> running TeX.  You then need to switch back to the document's buffer to
>> continue editing.  This behavior makes no sense.  It would be
>> equivalent to running `compile' on a C file, and then only seeing the
>> output from make/gcc/etc, with the source code hidden.  The correct
>> behavior in both cases is to show the process output in a window
>> alongside the source.  Anyone who has been using tex-mode for years
>> would certainly find this new behavior disruptive, although it is
>> easily corrected.
>>
>> I'm not sure if the `display-buffer' calls in tex-mode.el need to have
>> an action argument, but if they do, it should be similar to what is
>> used in compile.el.  I'll be the first to admit that I'm not
>> particularly well-versed in the current intricacies of buffer display
>> actions (nor do I have any real desire to become so :-).
>
> Adding Sam, who made these changes in tex-mode.el.

Eli, you sent your message to the amazon.com address. Why?
The commit is tagged with my correct gnu.org address.
Please only use sds@gnu.org for all communications.

>  Sam, any comments?

I do not use `tex-buffer', but C-c C-f (which runs the command
`tex-file') does exactly what it should - creates a new window showing
`*tex-shell*'. Moreover, I just tried C-c C-b (which runs the command
`tex-buffer') and it created a new `*tex-shell*' window too (or re-used
an existing one) without replacing the window that shows my LaTeX.

When I made the change, I was trying to fix
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52467 (re-use the existing
`*tex-shell*' window) and I think I did.

Jeff, could you please reproduce the issue in `emacs -Q`?

Thank you!

-- 
Sam Steingold (https://aphar.dreamwidth.org/) on Pop 22.04 (jammy) X 11.0.12101004
https://lastingimpactpsychology.com https://steingoldpsychology.com
https://honestreporting.com https://www.peaceandtolerance.org/
Live Lisp and prosper.

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

[Eli Zaretskii]

> From: Sam Steingold <sds@gnu.org>
> Date: Thu, 08 Jun 2023 13:44:40 -0400
> Posted-To: gmane.emacs.bugs
> 
> > Adding Sam, who made these changes in tex-mode.el.
> 
> Eli, you sent your message to the amazon.com address. Why?

Because that's what appears in Git:

  commit 18b680cfd177e877991be2bd70ead628bbdc0aa0
  Author:     Sam Steingold <sdsg@amazon.com>
  AuthorDate: Tue Dec 28 17:27:41 2021 -0500
  Commit:     Sam Steingold <sdsg@amazon.com>
  CommitDate: Tue Dec 28 17:28:49 2021 -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.

> 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.

> >  Sam, any comments?
> 
> I do not use `tex-buffer', but C-c C-f (which runs the command
> `tex-file') does exactly what it should - creates a new window showing
> `*tex-shell*'. Moreover, I just tried C-c C-b (which runs the command
> `tex-buffer') and it created a new `*tex-shell*' window too (or re-used
> an existing one) without replacing the window that shows my LaTeX.
> 
> When I made the change, I was trying to fix
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52467 (re-use the existing
> `*tex-shell*' window) and I think I did.
> 
> Jeff, could you please reproduce the issue in `emacs -Q`?

I tried "M-x tex-buffer RET" in "emacs -Q", and I see what Jeff
reports.  Are you sure you don't have any customizations that get in
the way?  Or maybe post the exact sequence of commands you tried?

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

[Jeff Norden]

On Thu, Jun 8,  Eli Zaretskii wrote:
> From: Eli Zaretskii
> To: Sam Steingold
> Cc: 63956 <at> debbugs.gnu.org
> Subject: Re: bug#63956: 29.0.91; tex-mode display problem in emacs-29
> Date: Thu, 08 Jun 2023 21:34:09 +0300
> ...
> > >  Sam, any comments?
> >
> > I do not use `tex-buffer', but C-c C-f (which runs the command
> > `tex-file') does exactly what it should - creates a new window showing
> > `*tex-shell*'. Moreover, I just tried C-c C-b (which runs the command
> > `tex-buffer') and it created a new `*tex-shell*' window too (or re-used
> > an existing one) without replacing the window that shows my LaTeX.
> > When I made the change, I was trying to fix
> > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52467 (re-use the existing
> > `*tex-shell*' window) and I think I did.
> >
> > Jeff, could you please reproduce the issue in `emacs -Q`?
>
> I tried "M-x tex-buffer RET" in "emacs -Q", and I see what Jeff
> reports.  Are you sure you don't have any customizations that get in
> the way?  Or maybe post the exact sequence of commands you tried?

At first I thought there was a misunderstanding about the intended
behavior, but then I realized that Sam is saying that his tex-shell
window *doesn't* replace the editing window.  I can also verify that it
does replace the editing window, using "emacs -Q" with either 29.0.91
or emacs-30 built from the current git source.  Since the default
display action is replace-window, this makes sense.

Sam: can you try it again after making sure that your
display-comint-buffer-action has the default value (which should be
'(display-buffer-same-window (inhibit-same-window))'?  If I'm
understanding things correctly, the point of this new variable is to
make it easier to modify the way normal *shell* type buffers open,
while leaving the traditional same-window behavior as the default.
---
My own tex-mode use is very heavily customized (via eval-after-load),
so I think I need to look a bit at the default behavior before I make
any specific suggestions about changing tex-mode.el.  I'll try to do
that this weekend.

-Jeff

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

[Sam Steingold]

> * Eli Zaretskii <ryvm@tah.bet> [2023-06-08 21:34:09 +0300]:
>
>> Eli, you sent your message to the amazon.com address. Why?
>
> Because that's what appears in Git:
>
>   commit 18b680cfd177e877991be2bd70ead628bbdc0aa0
>   Author:     Sam Steingold <sdsg@amazon.com>
>   AuthorDate: Tue Dec 28 17:27:41 2021 -0500
>   Commit:     Sam Steingold <sdsg@amazon.com>
>   CommitDate: Tue Dec 28 17:28:49 2021 -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'.

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.

>> 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.

> 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.

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

-- 
Sam Steingold (https://aphar.dreamwidth.org/) on Pop 22.04 (jammy) X 11.0.12101004
https://lastingimpactpsychology.com https://steingoldpsychology.com
https://ij.org/ https://camera.org https://honestreporting.com
Legends are time-tested rumors.

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.

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

[Gregory Heytings]

>
> 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.
>

The difference is that since Git 2.23.0 "git log" behaves by default as if 
the --mailmap option was given, which uses the correspondence in the 
.mailmap file.  The actual author of commit 18b680cfd1 is sdsg@amazon.com, 
but because of the line

Sam Steingold <sds@gnu.org> <sdsg@amazon.com>

in the .mailmap file the author is displayed as sds@gnu.org.

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

[Eli Zaretskii]

> Date: Sat, 10 Jun 2023 12:55:05 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: sds@gnu.org, Jeff Norden <norden.jeff@gmail.com>, 63956@debbugs.gnu.org, 
>     Stefan Monnier <monnier@iro.umontreal.ca>
> 
> > 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.
> >
> 
> The difference is that since Git 2.23.0 "git log" behaves by default as if 
> the --mailmap option was given, which uses the correspondence in the 
> .mailmap file.

Thanks (but I guess you meant --use-mailmap, not --mailmap).

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

[Gregory Heytings]

>>> 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.
>>
>> The difference is that since Git 2.23.0 "git log" behaves by default as 
>> if the --mailmap option was given, which uses the correspondence in the 
>> .mailmap file.
>
> Thanks (but I guess you meant --use-mailmap, not --mailmap).
>

Yes and no: --mailmap and --use-mailmap are equivalent since Git 2.27.0, 
as are --no-mailmap and --no-use-mailmap.

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

[Eli Zaretskii]

> Cc: 63956@debbugs.gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sat, 10 Jun 2023 08:56:50 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > 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.

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.

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

[Jeff Norden]

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

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

[Eli Zaretskii]

> From: Jeff Norden <norden.jeff@gmail.com>
> Date: Sun, 11 Jun 2023 10:44:38 -0500
> Cc: sds@gnu.org, 63956-done@debbugs.gnu.org, monnier@iro.umontreal.ca
> 
> I suggest just removing the actions from the two display-buffer calls
> and the pop-top-buffer call in tex-mode.el.

Meanwhile I installed a different fix: there's no a separate defcustom
display-tex-shell-buffer-action, whose default should do what you
want.  If it doesn't do what you want, please tell the details, and
let's take it from there.

IOW, please try the latest emacs-29 branch of the Emacs Git
repository, and see if tex-mode there behaves better.

Thanks.

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

[Jeff Norden]

On Sun, Jun 11, 2023 at 11:01 AM Eli Zaretskii <eliz@gnu.org> wrote:
...
> > I suggest just removing the actions from the two display-buffer calls
> > and the pop-top-buffer call in tex-mode.el.
>
> Meanwhile I installed a different fix: there's no a separate defcustom
> display-tex-shell-buffer-action, whose default should do what you
> want.  If it doesn't do what you want, please tell the details, and
> let's take it from there.
>
> IOW, please try the latest emacs-29 branch of the Emacs Git
> repository, and see if tex-mode there behaves better.

Works fine for me.  Using -tex-shell-buffer-action for a docview
buffer is perhaps a bit odd, but I'm sure you have more pressing
issues to deal with right now.  Again, apologies for the delay in
responding.
-Jeff

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

[Eli Zaretskii]

> From: Jeff Norden <norden.jeff@gmail.com>
> Date: Sun, 11 Jun 2023 12:31:54 -0500
> Cc: sds@gnu.org, 63956@debbugs.gnu.org, monnier@iro.umontreal.ca
> 
> On Sun, Jun 11, 2023 at 11:01 AM Eli Zaretskii <eliz@gnu.org> wrote:
> ...
> > > I suggest just removing the actions from the two display-buffer calls
> > > and the pop-top-buffer call in tex-mode.el.
> >
> > Meanwhile I installed a different fix: there's no a separate defcustom
> > display-tex-shell-buffer-action, whose default should do what you
> > want.  If it doesn't do what you want, please tell the details, and
> > let's take it from there.
> >
> > IOW, please try the latest emacs-29 branch of the Emacs Git
> > repository, and see if tex-mode there behaves better.
> 
> Works fine for me.

Great, thanks for testing.

> Using -tex-shell-buffer-action for a docview buffer is perhaps a bit
> odd

You could be right, but I couldn't find any callers of that function,
so it was hard for me to reason about that specific case.  Stefan,
since you introduced tex-cmd-doc-view into tex-mode.el, could you take
a look and tell whether using display-tex-shell-buffer-action in its
default value there makes sense?  If not, what would be a better
default?

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

[Jeff Norden]

On Sun, Jun 11, 2023 at 1:14 PM Eli Zaretskii wrote:
> ...
> > Using -tex-shell-buffer-action for a docview buffer is perhaps a bit
> > odd
>
> You could be right, but I couldn't find any callers of that function,
> so it was hard for me to reason about that specific case.  Stefan,
> since you introduced tex-cmd-doc-view into tex-mode.el, could you take
> a look and tell whether using display-tex-shell-buffer-action in its
> default value there makes sense?  If not, what would be a better
> default?

Took me a bit to figure that out.  Choosing the docview option from
`tex-compile' results in pre-pending "tex-cmd-" to "doc-view" and then
calling `tex-cmd-doc-view', which simply opens the pdf file (in
docview mode) with pop-to-buffer.  The other tex-compile commands that
preview the document do so by running an external program such as
ghostview or xdvi.  That is why I was thinking that opening in a new
frame might be appropriate.

I've never used tex-compile, and I wonder if it gets much use in
general.  One of the ideas I was thinking of was adding it as a
sub-menu of the TeX menubar entry, which would make it easier to use.
Another thing, which I now realize is already listed as a 'fixme' item
in tex-mode.el, is to check that, e.g., the corresponding pdf file is
up to date (newer than the tex source) before previewing it.

-Jeff

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

[Eli Zaretskii]

> From: Jeff Norden <norden.jeff@gmail.com>
> Date: Sun, 11 Jun 2023 15:12:08 -0500
> Cc: monnier@iro.umontreal.ca, sds@gnu.org, 63956@debbugs.gnu.org
> 
> On Sun, Jun 11, 2023 at 1:14 PM Eli Zaretskii wrote:
> > ...
> > > Using -tex-shell-buffer-action for a docview buffer is perhaps a bit
> > > odd
> >
> > You could be right, but I couldn't find any callers of that function,
> > so it was hard for me to reason about that specific case.  Stefan,
> > since you introduced tex-cmd-doc-view into tex-mode.el, could you take
> > a look and tell whether using display-tex-shell-buffer-action in its
> > default value there makes sense?  If not, what would be a better
> > default?
> 
> Took me a bit to figure that out.  Choosing the docview option from
> `tex-compile' results in pre-pending "tex-cmd-" to "doc-view" and then
> calling `tex-cmd-doc-view', which simply opens the pdf file (in
> docview mode) with pop-to-buffer.

OK, thanks.  But did you see any difference between doing this the way
Emacs 28 did (without 2nd argument to pop-to-buffer) and the way the
code now does on the emacs-29 branch?  IOW, does this scenario produce
reasonable results after my recent changes?

> The other tex-compile commands that
> preview the document do so by running an external program such as
> ghostview or xdvi.  That is why I was thinking that opening in a new
> frame might be appropriate.
> 
> I've never used tex-compile, and I wonder if it gets much use in
> general.  One of the ideas I was thinking of was adding it as a
> sub-menu of the TeX menubar entry, which would make it easier to use.
> Another thing, which I now realize is already listed as a 'fixme' item
> in tex-mode.el, is to check that, e.g., the corresponding pdf file is
> up to date (newer than the tex source) before previewing it.

Stefan, your comments on this, and in particular on the
tex-cmd-doc-view function, will be appreciated.

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

[Jeff Norden]

On Mon, Jun 12, 2023 at 6:48 AM Eli Zaretskii wrote:
> OK, thanks.  But did you see any difference between doing this the way
> Emacs 28 did (without 2nd argument to pop-to-buffer) and the way the
> code now does on the emacs-29 branch?  IOW, does this scenario produce
> reasonable results after my recent changes?

The default behavior in emacs-29 is now the same as it was in 28.2, so I
don't see any need to make further changes at this point.
---
If my (admittedly limited) understanding of display buffer actions is
correct, then calling display-buffer or pop-to-buffer with a
'reuse-window' action would only differ from a call without any action
if either:
  (a) display-buffer-base-action has been customized, or
  (b) the buffer name has been listed in same-window-buffer-names or
      matches same-window-regexps
This assumes that display-buffer-fallback-action has its default
value, which it should since it is defined with defconst in window.el:

 (defconst display-buffer-fallback-action
  '((display-buffer--maybe-same-window  ;FIXME: why isn't this redundant?
     display-buffer-reuse-window
     display-buffer--maybe-pop-up-frame-or-window
     display-buffer-in-previous-window
     display-buffer-use-some-window
     ;; If all else fails, pop up a new frame.
     display-buffer-pop-up-frame))

Perhaps this answers the question in the above code, --maybe-same-window
seems to be for backwards compatibility to allow the use of the
same-window- variables, which pre-date window actions.
Using display-buffer-alist is the recommended way to do things now, and
gets first priority.

Thanks,
-Jeff

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

[Eli Zaretskii]

> From: Jeff Norden <norden.jeff@gmail.com>
> Date: Mon, 12 Jun 2023 11:41:34 -0500
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, sds@gnu.org, 63956@debbugs.gnu.org
> 
> On Mon, Jun 12, 2023 at 6:48 AM Eli Zaretskii wrote:
> > OK, thanks.  But did you see any difference between doing this the way
> > Emacs 28 did (without 2nd argument to pop-to-buffer) and the way the
> > code now does on the emacs-29 branch?  IOW, does this scenario produce
> > reasonable results after my recent changes?
> 
> The default behavior in emacs-29 is now the same as it was in 28.2, so I
> don't see any need to make further changes at this point.

Thanks, good to know.

I'll leave it to display-buffer experts to comment on the other point
you made.

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> You could be right, but I couldn't find any callers of that function,
> so it was hard for me to reason about that specific case.  Stefan,
> since you introduced tex-cmd-doc-view into tex-mode.el, could you take
> a look and tell whether using display-tex-shell-buffer-action in its
> default value there makes sense?  If not, what would be a better
> default?

Hmm... when I introduced `tex-cmd-doc-view` it just used

    (pop-to-buffer (find-file-noselect file))

then when Sam Steingold introduced `display-comint-buffer-action` (in
commit 18b680cfd177) he used it there as well, but I suspect this was
a mistake because that command does not at all work like a comint thingy
(my guess is that he's an AUCTeX user and just assumed that
`tex-cmd-doc-view` is like other `tex-cmd-*` thingies).

I'm not sure it's harmful to use `display-comint-buffer-action` or
`display-tex-shell-buffer-action` there (e.g. I haven't noticed it being
a problem in my own use since Sam's patch), but it doesn't seem
necessary nor very natural (it's just not a "tex-shell" or "comint"
buffer, it's a normal file buffer).


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Jeff Norden <norden.jeff@gmail.com>,  sds@gnu.org,  63956@debbugs.gnu.org
> Date: Mon, 12 Jun 2023 21:34:19 -0400
> 
> Hmm... when I introduced `tex-cmd-doc-view` it just used
> 
>     (pop-to-buffer (find-file-noselect file))
> 
> then when Sam Steingold introduced `display-comint-buffer-action` (in
> commit 18b680cfd177) he used it there as well, but I suspect this was
> a mistake because that command does not at all work like a comint thingy
> (my guess is that he's an AUCTeX user and just assumed that
> `tex-cmd-doc-view` is like other `tex-cmd-*` thingies).
> 
> I'm not sure it's harmful to use `display-comint-buffer-action` or
> `display-tex-shell-buffer-action` there (e.g. I haven't noticed it being
> a problem in my own use since Sam's patch), but it doesn't seem
> necessary nor very natural (it's just not a "tex-shell" or "comint"
> buffer, it's a normal file buffer).

Thanks, I removed the 2nd argument of pop-to-buffer there.