--- Begin Message ---
|
Subject: |
Display monitor frames not warmed up |
|
Date: |
Wed, 27 Feb 2019 23:02:09 +0200 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) |
Sometimes desktop restoration fails with the error:
Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
+(nil nil -1)
frameset-move-onscreen(#<frame address@hidden 0x55a7cd486ed0> t)
frameset--restore-frame(... t)
frameset-restore([frameset ...] :reuse-frames t :cleanup-frames t
:force-display t :force-onscreen t)
desktop-restore-frameset()
desktop-read()
run-hooks(after-init-hook delayed-warnings-hook)
command-line()
normal-top-level()
because ‘frame-monitor-attributes’ in ‘frameset-move-onscreen’ returns ‘nil’.
It returns ‘nil’ because the attribute ‘frames’ returned by
‘display-monitor-attributes-list’ is empty, and ‘frame-monitor-attributes’
filters out the returned attributes if it can't find the arg ‘frame’ in
the list of frames.
However, when ‘display-monitor-attributes-list’ is “warmed up” with just
a ‘message’ call before its first call, its returned ‘frames’ contains
the arg ‘frame’.
I guess calling the function ‘message’ before calling
‘display-monitor-attributes-list’
performs some redisplay that adds the frame to the list of frames in
‘display-monitor-attributes-list’.
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#34680: Display monitor frames not warmed up |
|
Date: |
Tue, 19 Mar 2019 23:43:34 +0200 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) |
>>>> I guess calling the function ‘message’ before calling
>>>> ‘display-monitor-attributes-list’ performs some redisplay that adds
>>>> the frame to the list of frames in ‘display-monitor-attributes-list’.
>>>
>>> It also fixes the issue when using any of the following
>>> ‘redisplay’, ‘redraw-display’, ‘redraw-frame’, or just
>>> ‘display-monitor-attributes-list’ before calling
>>> ‘frame-monitor-attributes’ for the first time.
>>>
>>> Just calling ‘display-monitor-attributes-list’ somehow “registers” the
>>> frame in the list of frames, so the next call of
>>> ‘display-monitor-attributes-list’
>>> returns the attribute ‘frames’ containing the frame.
>>
>> I can't explain this, but this is the minimal patch that fixes my
>> problem. This dry run by calling gdk_display_get_monitor_at_window
>> ignores its first wrong return value, so its subsequent calls return
>> correct values.
>
> I discovered this is a known problem yet unfixed for many years:
>
> https://debbugs.gnu.org/19706
> 25.0.50; (+ nil nil -1) in desktop-restore-frameset
As a last resort, I installed this patch as panacea for all such bugs:
diff --git a/lisp/frame.el b/lisp/frame.el
index c5802e30b6..7cfe546ca6 100644
--- a/lisp/frame.el
+++ b/lisp/frame.el
@@ -1696,7 +1696,10 @@ frame-monitor-attributes
(or frame (setq frame (selected-frame)))
(cl-loop for attributes in (display-monitor-attributes-list frame)
for frames = (cdr (assq 'frames attributes))
- if (memq frame frames) return attributes))
+ if (memq frame frames) return attributes
+ ;; On broken frames monitor attributes,
+ ;; fall back to the last monitor.
+ finally return attributes))
(defun frame-monitor-attribute (attribute &optional frame x y)
"Return the value of ATTRIBUTE on FRAME's monitor.
--- End Message ---