Subject: bug#34680: closed (Re: bug#34680: Display monitor frames not warmed up)

From: [email-masked] (GNU bug Tracking System)
Date: Tue, 19 Mar 2019 21:45:02 +0000

Your bug report

#34680: Display monitor frames not warmed up

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
34680: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=34680
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#34680: Display monitor frames not warmed up
From: Juri Linkov <[email-masked]>
To: [email-masked]
Date: Tue, 19 Mar 2019 23:43:34 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

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

Subject: Display monitor frames not warmed up
From: Juri Linkov <[email-masked]>
To: [email-masked]
Date: Wed, 27 Feb 2019 23:02:09 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

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 emacs@localhost 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’.