[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#39977: 28.0.50; Unhelpful stack trace

From: martin rudalics
Subject: bug#39977: 28.0.50; Unhelpful stack trace
Date: Sun, 22 Mar 2020 19:20:33 +0100

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

Once an initial frame has been created, Lisp code should be always able
to rely on the truth of

(and (frame-live-p (selected-frame))
     (window-live-p (selected-window))
     (eq (frame-selected-window (selected-frame))

Whenever this basic invariant is violated, there is no guarantee that
frame and window management will produce correct results.  Currently,
this invariance is no longer guaranteed if Lisp code is allowed to
manipulate frames and windows arbitrarily while processing the mode line
or the frame title.  IMO there are three possible ways to deal with this

(1) Let the redisplay code handle it.

(2) Let the frame and window management handle it by disallowing such
operations while they are issued by the mode line or frame title
processing code.

(3) Ignore it and let the frame/window management routines catch up with
it later.

Using (1) way my initial idea.  The patch I proposed handles simple
cases like Madhu's bug.  It will certainly not handle more sophisticated
cases where, for example, an application kills two frames in a row.

(2) is by far the most simple and reliable approach but it will restrict
applications in what they are allowed to do when processing a mode line
or frame title.

(3) means that frame/window management proceeds in a non-deterministic
fashion as long as it has not detected that its basic invariant has been

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

You again care about redisplay only.  Which means that frame/window
management is second-class as far as safety is concerned.

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

I attach a patch that does that.  If you try it with a recipe like

(defvar foo
    (when (> (length (frame-list)) 1)
      (delete-frame (next-frame)))))

(setq-default mode-line-format foo)


with emacs -Q you will see that while it works around the crash it still
produces a

Wrong type argument: window-live-p, #<window 3>

error in redisplay.


Attachment: SELECTD_FRAME.diff
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]