From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Backtrace printing in batch mode ignores all customizations Date: Tue, 14 Jan 2020 15:30:24 -0500 Message-ID: References: <83h80y59l6.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="253407"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: pogonyshev@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jan 14 21:31:29 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1irSqW-0013Q0-Td for ged-emacs-devel@m.gmane-mx.org; Tue, 14 Jan 2020 21:31:29 +0100 Original-Received: from localhost ([::1]:45692 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1irSqV-0004S9-DZ for ged-emacs-devel@m.gmane-mx.org; Tue, 14 Jan 2020 15:31:27 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46388) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1irSpu-00041t-4M for emacs-devel@gnu.org; Tue, 14 Jan 2020 15:30:53 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1irSpq-0000px-34 for emacs-devel@gnu.org; Tue, 14 Jan 2020 15:30:49 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:43027) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1irSpb-0000Cg-6Y; Tue, 14 Jan 2020 15:30:31 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 47B6982C46; Tue, 14 Jan 2020 15:30:29 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id F1BA5803D6; Tue, 14 Jan 2020 15:30:26 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1579033827; bh=Vgo6un66aW4rJKT4ucMK+h1i01xIUPPjlnaEN/wuZWc=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=JmXJapjTTVsuDlZnzY2VoHvVwURcb4gid4GNHKoWkw9mMsRPEGHGdgP4GUCsfkKf9 dwAzjpxmezM6bRCEZY2DupLyTIA4gXa/8DQ467klF+sV7Tcd1mMJ5aNrDxIbhbwqpS z5niHjddXQ0om8howwf1VnTX7BQgnI35UR8TbTfbDDmEDwOhJhU5+iErF0oI9hu6xc GeS/yQL8zUJUNWagRTm1GM3BkYqigGJaVeAFlBRYr/AnVydTeYLlaeKxwUoQjjDR/y sGHezJXXk+pVY6vPi9hxeXGrxuXs80qJC6F9jvS6mzQsh+ozy8pQ4JizliUVUrFs6O z8yByz+a4w9Hg== Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id DFD29120D97; Tue, 14 Jan 2020 15:30:26 -0500 (EST) In-Reply-To: <83h80y59l6.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 14 Jan 2020 17:41:41 +0200") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 132.204.25.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:244262 Archived-At: > Paul said earlier that the latter condition, which tests > terminal-name, is always correct in batch mode. If that is indeed so, > then why do we need to test noninteractive as well? it's redundant, > no? Indeed, it is. > And the request is to add a comment explaining the semantics of > only-backtrace. Not how it is set -- this is clear from the code, -- > but what does it mean in terms of the code after that which uses the > value. Because I don't think the name is descriptive enough, and the > value is tested more than once below. Agreed. > Btw, I'd be much happier if the condition didn't rely on low-level > implementation details such as the actual name of the initial > terminal, nor on when exactly during startup that terminal gets > deleted. I think it would be much cleaner to set a variable at the > right place in startup.el (AFAIU, after we call frame-initialize), and > test it in debug.el. I realize that this condition was copied from > the code we already had in debug.el, but maybe on master we should use > a cleaner solution. Setting a var wouldn't be right. The test: (and (eq t (framep (selected-frame))) (equal "initial_terminal" (terminal-name))) is fundamentally *right*: we want this special behavior when we're operating in the special dummy(stdin/out) terminal because that terminal does not offer the usual interaction expected by the normal backtrace debugger. So the `noninteractive` is an approximation (and is redundant for that same reason) whereas the above test is really the correct one. I agree that it is ugly because (framep (selected-frame)) returns `t` both for "normal" tty frames/terminals as well as for the special dummy terminal, so we need to depend on a special terminal name to distinguish those two cases. Maybe we can improve the code by introducing a function (defun terminal-dummy-p () "Return non-nil if the current terminal is the special initial terminal. The \"initial\" terminal is the dummy-terminal used when we don't have a real terminal to use, such as is the case in batch mode, or while running early-init.el, or while starting the emacs-server." (and (eq t (framep (selected-frame))) (equal "initial_terminal" (terminal-name))) and then use it there (and maybe we could then cleanup that function so it doesn't need to rely on a special terminal name). Stefan