GNU bug report logs - #39977
28.0.50; Unhelpful stack trace

Previous Next

Full log

Message #92 received at 39977 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: enometh <at> meer.net, 39977 <at> debbugs.gnu.org
Subject: Re: bug#39977: 28.0.50; Unhelpful stack trace
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.

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

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

martin

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.