From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#63956: 29.0.91; tex-mode display problem in emacs-29 Date: Sat, 10 Jun 2023 08:56:50 +0300 Message-ID: <837csb2731.fsf@gnu.org> References: <83h6ri2u2i.fsf@gnu.org> <87ttvhkfw7.fsf@gnu.org> <8335313ise.fsf@gnu.org> <87o7lojthj.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29095"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 63956@debbugs.gnu.org, Stefan Monnier To: sds@gnu.org, Jeff Norden Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jun 10 07:57:26 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1q7rbJ-0007Pt-N9 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 10 Jun 2023 07:57:25 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q7ray-000107-Gb; Sat, 10 Jun 2023 01:57:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q7rax-0000zy-2b for bug-gnu-emacs@gnu.org; Sat, 10 Jun 2023 01:57:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1q7raw-0004w3-P8 for bug-gnu-emacs@gnu.org; Sat, 10 Jun 2023 01:57:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1q7raw-0005kn-7M for bug-gnu-emacs@gnu.org; Sat, 10 Jun 2023 01:57:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 10 Jun 2023 05:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63956 X-GNU-PR-Package: emacs Original-Received: via spool by 63956-submit@debbugs.gnu.org id=B63956.168637661322100 (code B ref 63956); Sat, 10 Jun 2023 05:57:02 +0000 Original-Received: (at 63956) by debbugs.gnu.org; 10 Jun 2023 05:56:53 +0000 Original-Received: from localhost ([127.0.0.1]:33087 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7ram-0005kO-IX for submit@debbugs.gnu.org; Sat, 10 Jun 2023 01:56:52 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:49024) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7ral-0005kA-3N for 63956@debbugs.gnu.org; Sat, 10 Jun 2023 01:56:51 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q7rac-0004tm-7i; Sat, 10 Jun 2023 01:56:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=fCfHrE0BXUHyMbR4ugvFRZ5RP2ccgSyoxssqTMWOVGs=; b=J0BOlrTVCvX1 Y+uGqzWCrBRIReH1NjyjNKb2icZ8MU9iCIcoGI7vQHLDhMOdo/vdgMjfbHyle57CW3FraWbzg7Hqx w5F4TxP1YnNGjfAD9bzuEj5SdAsU3zZ4ii3WG3LTOsf1ywY4n9AViUZRJCbmpEVWIQ4ATeFQoXEEY 0cnmYCFyG8ZdDmRnQUo6pOxeLKfbzarh/WozI24fZ4K+OCrImrJjaYFim1YzHCdnBUkc0nXuAw/5Q ZvYNHkTk05bCtbruoofga1Jre1TY9QUy8VQyTEoEUJQpIzH47lW2badON5LnKx0nXb1oysaA7jpPP jdFLsBdSNs8LS1aWRH1yZg==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q7raa-00006b-E4; Sat, 10 Jun 2023 01:56:42 -0400 In-Reply-To: <87o7lojthj.fsf@gnu.org> (message from Sam Steingold on Fri, 09 Jun 2023 16:00:56 -0400) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:263190 Archived-At: > From: Sam Steingold > Date: Fri, 09 Jun 2023 16:00:56 -0400 > > here is what I see: > > commit 18b680cfd177e877991be2bd70ead628bbdc0aa0 > Author: Sam Steingold > 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.