unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Jeff Norden <norden.jeff@gmail.com>, Sam Steingold <sdsg@amazon.com>
Cc: 63956@debbugs.gnu.org
Subject: bug#63956: 29.0.91; tex-mode display problem in emacs-29
Date: Thu, 08 Jun 2023 12:15:49 +0300	[thread overview]
Message-ID: <83h6ri2u2i.fsf@gnu.org> (raw)
In-Reply-To: <CAPbFCnmaNPxu20=9g+nbc7s2T+Mxt8QU3kN7OMuu+voEwxmwPA@mail.gmail.com> (message from Jeff Norden on Wed, 7 Jun 2023 12:52:10 -0500)

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





  reply	other threads:[~2023-06-08  9:15 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 [this message]
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
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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=83h6ri2u2i.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=63956@debbugs.gnu.org \
    --cc=norden.jeff@gmail.com \
    --cc=sdsg@amazon.com \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).