From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#39977: 28.0.50; Unhelpful stack trace Date: Thu, 19 Mar 2020 16:33:53 +0200 Message-ID: <83zhcce7n2.fsf@gnu.org> References: <83zhcs80e5.fsf@gnu.org> <83imj88tpt.fsf@gnu.org> <550fbc22-09db-d30b-c194-8f26b5dca05f@gmx.at> <83wo7o6nxs.fsf@gnu.org> <60dd4ced-a2e5-ed17-0570-b7bdd2a557af@gmx.at> <83blozckn2.fsf@gnu.org> <01305dbc-c69b-baf9-f0bf-1e5b8c04d970@gmx.at> <83y2s2bswl.fsf@gnu.org> <3ac189d0-5d05-fdf9-0922-0c464b1b17c3@gmx.at> <83k13lbgux.fsf@gnu.org> <83d09cb9gz.fsf@gnu.org> <69a74f9e-079b-a771-0213-f60ed0bf5720@gmx.at> <83y2rzf08m.fsf@gnu.org> <7a0b9999-6778-6235-fbc9-2a24b4e3bc53@gmx.at> <83tv2mg9j0.fsf@gnu.org> <9684641c-a59a-4ed6-a6b4-d3238f789050@gmx.at> <83sgi6g461.fsf@gnu.org> <90ac4084-4fbb-b5d7-6a7c-597d8f08e88a@gmx.at> <83imj1g1eu.fsf@gnu.org> <835zf1fobf.fsf@gnu.org> <4472dbf8-eec0-72eb-a4ad-c6b382d27f1f@gmx.at> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="24546"; mail-complaints-to="usenet@ciao.gmane.io" Cc: enometh@meer.net, 39977@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Mar 19 15:35:16 2020 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 1jEwGS-0006HT-FC for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 19 Mar 2020 15:35:16 +0100 Original-Received: from localhost ([::1]:38858 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jEwGR-0000IK-Eu for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 19 Mar 2020 10:35:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49595) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jEwGF-0000Hn-LM for bug-gnu-emacs@gnu.org; Thu, 19 Mar 2020 10:35:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jEwGE-0004Pt-HS for bug-gnu-emacs@gnu.org; Thu, 19 Mar 2020 10:35:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37494) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jEwGE-0004Pl-Dt for bug-gnu-emacs@gnu.org; Thu, 19 Mar 2020 10:35:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jEwGE-0008Qa-61 for bug-gnu-emacs@gnu.org; Thu, 19 Mar 2020 10:35: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: Thu, 19 Mar 2020 14:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 39977 X-GNU-PR-Package: emacs Original-Received: via spool by 39977-submit@debbugs.gnu.org id=B39977.158462844532313 (code B ref 39977); Thu, 19 Mar 2020 14:35:02 +0000 Original-Received: (at 39977) by debbugs.gnu.org; 19 Mar 2020 14:34:05 +0000 Original-Received: from localhost ([127.0.0.1]:43467 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jEwFJ-0008P7-5W for submit@debbugs.gnu.org; Thu, 19 Mar 2020 10:34:05 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:34315) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jEwFG-0008OT-PC for 39977@debbugs.gnu.org; Thu, 19 Mar 2020 10:34:03 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:48282) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1jEwFA-000385-Vl; Thu, 19 Mar 2020 10:33:57 -0400 Original-Received: from [176.228.60.248] (port=1677 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jEwF8-00083T-AT; Thu, 19 Mar 2020 10:33:56 -0400 In-Reply-To: <4472dbf8-eec0-72eb-a4ad-c6b382d27f1f@gmx.at> (message from martin rudalics on Thu, 19 Mar 2020 09:55:07 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 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" Xref: news.gmane.io gmane.emacs.bugs:177543 Archived-At: > Cc: enometh@meer.net, 39977@debbugs.gnu.org > From: martin rudalics > Date: Thu, 19 Mar 2020 09:55:07 +0100 > > >> We already disallow deleting the last live or visible frame and the last > >> window on a frame. > > > > Those situations are easy to detect, so we do that. > > For some value of easy. Relatively easy. > > You are now > > proposing something more sophisticated than that, and I'm afraid that > > doing so is not as straightforward as in those few simple cases we > > already handle. > > I'm afraid that we already might mishandle some of those simple cases. That just makes my point stronger, doesn't it? > >> So the redisplay code, whenever it runs Lisp in between, could > >> simply set a boolean that will disallow deleting any window or frame > >> as well as setting the window configuration and other dangerous > >> operations that implicitly might kill a window or a buffer. > > > > The problem is how to do this without breaking legitimate code. For > > example, changing the window configuration temporarily, then changing > > it back is quite legitimate, > > Right in the middle of redisplay, while constructing the mode line or > the title format? Why not? As long as things are back as they were by the time :eval returns, I see no reason to disallow such code. > > so summarily disallowing such actions is > > too drastic and will be hard to justify. > [...] > > All we need to do is avoid crashing and keeping the display > > up-to-date; any other outcome: error messages, code that doesn't do > > what the author expected/intended, and any other annoyance -- are > > completely fine, because whoever writes such nasty code will learn a > > lesson. > > Hmmm... I thought we have all those emacs_abort instances to ease > debugging. No, they are there in cases where we simply don't know how to continue.