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: Sat, 21 Mar 2020 15:15:42 +0200 Message-ID: <838sjtetmp.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> <83zhcce7n2.fsf@gnu.org> <9a3df43d-4a83-bed0-9ad1-b59cf11b4c9c@gmx.at> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="54354"; 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 Sat Mar 21 14:16:13 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 1jFdz2-000E2L-S2 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 21 Mar 2020 14:16:12 +0100 Original-Received: from localhost ([::1]:36652 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jFdz1-00036P-UU for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 21 Mar 2020 09:16:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47689) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jFdyt-00034D-ME for bug-gnu-emacs@gnu.org; Sat, 21 Mar 2020 09:16:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jFdys-0003en-In for bug-gnu-emacs@gnu.org; Sat, 21 Mar 2020 09:16:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40124) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jFdys-0003eR-F9 for bug-gnu-emacs@gnu.org; Sat, 21 Mar 2020 09:16:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jFdys-0006V4-Bu for bug-gnu-emacs@gnu.org; Sat, 21 Mar 2020 09:16: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, 21 Mar 2020 13:16: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.158479655524975 (code B ref 39977); Sat, 21 Mar 2020 13:16:02 +0000 Original-Received: (at 39977) by debbugs.gnu.org; 21 Mar 2020 13:15:55 +0000 Original-Received: from localhost ([127.0.0.1]:46097 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jFdyl-0006Uk-De for submit@debbugs.gnu.org; Sat, 21 Mar 2020 09:15:55 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:60756) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jFdyj-0006UX-BX for 39977@debbugs.gnu.org; Sat, 21 Mar 2020 09:15:53 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:44962) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1jFdyc-00030w-Ch; Sat, 21 Mar 2020 09:15:47 -0400 Original-Received: from [176.228.60.248] (port=3435 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jFdyY-0007wC-Tb; Sat, 21 Mar 2020 09:15:45 -0400 In-Reply-To: <9a3df43d-4a83-bed0-9ad1-b59cf11b4c9c@gmx.at> (message from martin rudalics on Sat, 21 Mar 2020 10:32:24 +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:177594 Archived-At: > Cc: enometh@meer.net, 39977@debbugs.gnu.org > From: martin rudalics > Date: Sat, 21 Mar 2020 10:32:24 +0100 > > >> I'm afraid that we already might mishandle some of those simple cases. > > > > That just makes my point stronger, doesn't it? > > Not really. It's easy for delete_frame to refuse deleting a frame right > at the beginning. But once it has accepted a deletion, it might become > hard to deal with all the consequences. I don't think I understand where you are going with this. > >> > 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. > > Such a change in the window configuration would take place in a state > where certain variables have temporary settings only. Selected frame, > selected window and current buffer have been set by redisplay in a fast, > improvised manner. I would never trust the outcome of save_window_save > or 'set-window-configuration' in such a state. This isn't about trust. This is about letting users' Lisp do anything they want as long as the results allow redisplay to continue after that Lisp returns. I don't think it's right to disallow certain actions just because they _might_ cause problems. > > No, they are there in cases where we simply don't know how to > > continue. > > If that's the reason, then SELECTED_FRAME can easily set selected_frame > to some live frame and continue. Something like that, yes.