all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: sds@gnu.org, Jeff Norden <norden.jeff@gmail.com>
Cc: 63956@debbugs.gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>
Subject: bug#63956: 29.0.91; tex-mode display problem in emacs-29
Date: Sat, 10 Jun 2023 08:56:50 +0300	[thread overview]
Message-ID: <837csb2731.fsf@gnu.org> (raw)
In-Reply-To: <87o7lojthj.fsf@gnu.org> (message from Sam Steingold on Fri, 09 Jun 2023 16:00:56 -0400)

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





  reply	other threads:[~2023-06-10  5:56 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-07 17:52 bug#63956: 29.0.91; tex-mode display problem in emacs-29 Jeff Norden
2023-06-08  9:15 ` Eli Zaretskii
2023-06-08 17:44   ` Sam Steingold
2023-06-08 18:34     ` Eli Zaretskii
2023-06-09 20:00       ` Sam Steingold
2023-06-10  5:56         ` Eli Zaretskii [this message]
2023-06-10 12:55           ` Gregory Heytings
2023-06-10 13:12             ` Eli Zaretskii
2023-06-10 13:20               ` Gregory Heytings
2023-06-11  6:22           ` Eli Zaretskii
2023-06-11 15:44             ` Jeff Norden
2023-06-11 16:01               ` Eli Zaretskii
2023-06-11 17:31                 ` Jeff Norden
2023-06-11 18:14                   ` Eli Zaretskii
2023-06-11 20:12                     ` Jeff Norden
2023-06-12 11:49                       ` Eli Zaretskii
2023-06-12 16:41                         ` Jeff Norden
2023-06-12 16:44                           ` Eli Zaretskii
2023-06-13  1:34                     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-13 11:12                       ` Eli Zaretskii
2023-06-09 16:30   ` Jeff Norden

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=837csb2731.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=63956@debbugs.gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=norden.jeff@gmail.com \
    --cc=sds@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.