GNU bug report logs - #25511
26.0.50; modify-frame-parameters modifies undesignated parameter?

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 25511 in the body.
You can then email your comments to 25511 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Katsumi Yamaoka <yamaoka <at> jpl.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.0.50; modify-frame-parameters modifies undesignated parameter?
Date: Mon, 23 Jan 2017 16:28:35 +0900

Hi,

This didn't happen last week, and doesn't happen with Emacs 25.1.
I have two displays arranged up and down; one is the up side of
1920x1080 and the other is the down side of 1366x768, i.e.:
+---------------+
|               |
|               |
|   1920x1080   | External display
|               |
|               |
+--+---------+--+
   |         |
   |1366x 768|    Note PC
   |         |
   +---------+
The coordinates start with (0 0) and (256 1080) respectively[1].
In that situation, the following script makes a new frame protrude
to the left from the down screen:

(let ((frame (make-frame)))
  (modify-frame-parameters frame '((top . 1200))))

On the new frame, (frame-parameter nil 'left) returns 8, that is
outside of the down screen.  This happens whichever the original
frame (that runs the script) exists in the up screen or the down
screen.  As mentioned above, a new frame did not protrude from
the down screen last week.  Here is a workaround:

(let ((frame (make-frame)))
  (sit-for 0)
  (modify-frame-parameters frame '((top . 1200))))

But it is needless, isn't it?

Thanks in advance.
Regards,

In GNU Emacs 26.0.50.1 (i686-pc-cygwin, GTK+ Version 3.18.9)
 of 2017-01-23 built on yamaoka-PC
Windowing system distributor 'The Cygwin/X Project', version 11.0.11900000

[1] The values of left and top frame parameters seem to indicate
    that of a window of an Emacs frame, so we have to increase
    the values some extent.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Katsumi Yamaoka <yamaoka <at> jpl.org>, 25511 <at> debbugs.gnu.org
Subject: Re: bug#25511: 26.0.50; modify-frame-parameters modifies undesignated
 parameter?
Date: Mon, 23 Jan 2017 09:03:35 +0100

> The coordinates start with (0 0) and (256 1080) respectively[1].
> In that situation, the following script makes a new frame protrude
> to the left from the down screen:
>
> (let ((frame (make-frame)))
>    (modify-frame-parameters frame '((top . 1200))))

Why don't you use

(make-frame '((top . 1200)))

in the first place?  This should tell the window manager right away what
position you want before making the frame visible.  If this does not
work as intended, we shall have to investigate it.

As a general rule: Never set a frame parameter right after creating a
new frame.

> On the new frame, (frame-parameter nil 'left) returns 8, that is
> outside of the down screen.  This happens whichever the original
> frame (that runs the script) exists in the up screen or the down
> screen.  As mentioned above, a new frame did not protrude from
> the down screen last week.  Here is a workaround:
>
> (let ((frame (make-frame)))
>    (sit-for 0)
>    (modify-frame-parameters frame '((top . 1200))))
>
> But it is needless, isn't it?

IIUC your approach worked because of a busy loop in x_make_frame_visible
which has been removed a few days ago.  I back its removal so you should
be able to do without it.

> [1] The values of left and top frame parameters seem to indicate
>      that of a window of an Emacs frame, so we have to increase
>      the values some extent.

I'm not sure I can follow you here.  The `top' and `left' frame
parameters usually indicate the top/left position of the window manager
frame that has reparented the outermost widget of your Emacs frame.
What do you have to "increase"?

martin

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

From: Katsumi Yamaoka <yamaoka <at> jpl.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 25511 <at> debbugs.gnu.org
Subject: Re: bug#25511: 26.0.50;
 modify-frame-parameters modifies undesignated parameter?
Date: Mon, 23 Jan 2017 18:01:06 +0900

On Mon, 23 Jan 2017 09:03:35 +0100, martin rudalics wrote:
>> The coordinates start with (0 0) and (256 1080) respectively[1].
>> In that situation, the following script makes a new frame protrude
>> to the left from the down screen:
>>
>> (let ((frame (make-frame)))
>>    (modify-frame-parameters frame '((top . 1200))))

> Why don't you use

> (make-frame '((top . 1200)))

> in the first place?  This should tell the window manager right away what
> position you want before making the frame visible.  If this does not
> work as intended, we shall have to investigate it.

Yes, it and even (make-frame) work with no problem.

> As a general rule: Never set a frame parameter right after creating a
> new frame.

Ok, I can modify some codes similar to it.

>> On the new frame, (frame-parameter nil 'left) returns 8, that is
>> outside of the down screen.  This happens whichever the original
>> frame (that runs the script) exists in the up screen or the down
>> screen.  As mentioned above, a new frame did not protrude from
>> the down screen last week.  Here is a workaround:
>>
>> (let ((frame (make-frame)))
>>    (sit-for 0)
>>    (modify-frame-parameters frame '((top . 1200))))
>>
>> But it is needless, isn't it?

> IIUC your approach worked because of a busy loop in x_make_frame_visible
> which has been removed a few days ago.  I back its removal so you should
> be able to do without it.

I found the change in question in git log after sending the
report.  I don't ask you to revert it as it seems to have been
a burden sort of.

>> [1] The values of left and top frame parameters seem to indicate
>>      that of a window of an Emacs frame, so we have to increase
>>      the values some extent.

> I'm not sure I can follow you here.  The `top' and `left' frame
> parameters usually indicate the top/left position of the window manager
> frame that has reparented the outermost widget of your Emacs frame.
> What do you have to "increase"?

In order not to hide the matte that includes the title bar, the
menu bar, and the tool bar.  In reality on Cygwin, the form

(make-frame '((left . 0) (top . 0)))

doesn't work as expected; the new frame appears on the down
screen and the position is erratic.  The minimum values that
display a new frame fully on the top-left corner of the upper
screen is:

(make-frame '((left . 0) (top . 1)))

But frame-parameters shows left=8 and top=32 in that case.

Anyway thanks for your help.  I will close this bug later.

Regards,

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

From: martin rudalics <rudalics <at> gmx.at>
To: Katsumi Yamaoka <yamaoka <at> jpl.org>
Cc: 25511 <at> debbugs.gnu.org
Subject: Re: bug#25511: 26.0.50; modify-frame-parameters modifies undesignated
 parameter?
Date: Mon, 23 Jan 2017 11:28:14 +0100

>> As a general rule: Never set a frame parameter right after creating a
>> new frame.
>
> Ok, I can modify some codes similar to it.

Try to avoid ‘modify-frame-parameters’ wherever it's possible.  There
might be still cases left where we have to use it because some frame
parameters cannot be processed on an invisible frame.  That's enough
trouble.

> In order not to hide the matte that includes the title bar, the
> menu bar, and the tool bar.  In reality on Cygwin, the form
>
> (make-frame '((left . 0) (top . 0)))
>
> doesn't work as expected; the new frame appears on the down
> screen and the position is erratic.

Can you try this with a native Windows build and compare the behaviors?

> The minimum values that
> display a new frame fully on the top-left corner of the upper
> screen is:
>
> (make-frame '((left . 0) (top . 1)))
>
> But frame-parameters shows left=8 and top=32 in that case.

What does a specification like

(make-frame '((left . (+ -8)) (top . (+ -32))))

give here?

martin

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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 25511 <at> debbugs.gnu.org, Katsumi Yamaoka <yamaoka <at> jpl.org>
Subject: Re: bug#25511: 26.0.50;
 modify-frame-parameters modifies undesignated parameter?
Date: Mon, 23 Jan 2017 12:27:23 -0500

On Mon, Jan 23, 2017 at 3:03 AM, martin rudalics <rudalics <at> gmx.at> wrote:
>
>> On the new frame, (frame-parameter nil 'left) returns 8, that is
>> outside of the down screen.  This happens whichever the original
>> frame (that runs the script) exists in the up screen or the down
>> screen.  As mentioned above, a new frame did not protrude from
>> the down screen last week.  Here is a workaround:
>>
>> (let ((frame (make-frame)))
>>    (sit-for 0)
>>    (modify-frame-parameters frame '((top . 1200))))
>>
>> But it is needless, isn't it?
>
> IIUC your approach worked because of a busy loop in x_make_frame_visible
> which has been removed a few days ago.  I back its removal so you should
> be able to do without it.

Should we change modify-frame-parameters to delay the actual
modification until the frame turns visible?

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

From: martin rudalics <rudalics <at> gmx.at>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 25511 <at> debbugs.gnu.org, Katsumi Yamaoka <yamaoka <at> jpl.org>
Subject: Re: bug#25511: 26.0.50; modify-frame-parameters modifies undesignated
 parameter?
Date: Mon, 23 Jan 2017 19:01:46 +0100

> Should we change modify-frame-parameters to delay the actual
> modification until the frame turns visible?

In a sense yes, see also Bug#24526.  Usually, we should be able to set
positions and sizes via the WM size hints right away so the window
manager can pick them up there whenever it maps the frame.  On Windows
there is a special function to set the sizes of an invisible window.

But all this should be done independently from setting up a new frame
that is supposed to become visible immediately.  In that latter case
‘modify-frame-parameters’ should not be used in the first place.

martin

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

From: Katsumi Yamaoka <yamaoka <at> jpl.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 25511 <at> debbugs.gnu.org
Subject: Re: bug#25511: 26.0.50;
 modify-frame-parameters modifies undesignated parameter?
Date: Tue, 24 Jan 2017 07:54:29 +0900

On Mon, 23 Jan 2017 11:28:14 +0100, martin rudalics wrote:
> Try to avoid ‘modify-frame-parameters’ wherever it's possible.  There
> might be still cases left where we have to use it because some frame
> parameters cannot be processed on an invisible frame.  That's enough
> trouble.

The main reason I use modify-frame-parameters is that a new frame
protrudes beyond the task-bar (placed at the bottom of the lower
screen) and so, I can't see the modeline and can't access the
mini-buffer on Cygwin, i.e.,
+----------------+
|  +-------+     |
|  |       |     |
|  | Emacs |     |
|  | frame |     |
|  |       |     |
+----------------+
|    Task-bar    |
+----------------+
Possible solutions to help it would be to make the task-bar
hidden automatically, to shrink the height of a new Emacs frame
by some sort of means, or to move a new frame upward...  Instead
of dragging it manually I use:

(defadvice make-frame (after adjust-frame-height-and-position activate)
  "Shrink the height of a new frame and move it upward."
  (if (ad-get-arg 0) nil
    (sit-for 0) ;; Added for new Emacs 26
    (modify-frame-parameters ad-return-value
                             '((height . 32) (top . 1112)))))

> Can you try this with a native Windows build and compare the behaviors?

Ok, I'll try the binary distribution.

> What does a specification like
> (make-frame '((left . (+ -8)) (top . (+ -32))))
> give here?

No difference with (make-frame).  The new frame appears on
the lower screen, mode-line and minibuffer is hidden, and
`frame-parameters' shows:

((top . 1137) (left . 292) (width . 80) (height . 36))

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

From: Katsumi Yamaoka <yamaoka <at> jpl.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 25511 <at> debbugs.gnu.org
Subject: Re: bug#25511: 26.0.50;
 modify-frame-parameters modifies undesignated parameter?
Date: Tue, 24 Jan 2017 09:45:37 +0900

On Tue, 24 Jan 2017 07:54:29 +0900, Katsumi Yamaoka wrote:
> On Mon, 23 Jan 2017 11:28:14 +0100, martin rudalics wrote:
>> Can you try this with a native Windows build and compare the behaviors?
> Ok, I'll try the binary distribution.

I tried emacs-25-20161227T071030Z-bin-i686-mingw32.7z in:
<https://sourceforge.net/p/emacs-bin/activity/?page=0&limit=100#58638d5fe88f3d01f432e025>

(make-frame '((left . 0) (top . 0)))
launches a new frame on the top-left corner of the *lower* screen,
the position and the size are:
((top . 0) (left . 0) (width . 80) (height . 36))
It varies to
((top + -1076) (left + -258) (width . 80) (height . 36))
after moving it to the top-left corner of the upper screen.
I feel it a very good behavior.

As for the eclipse of the bottom of an Emacs frame by the task-
bar, it doesn't happen by default.  However, it seems to be due
to the size of the default font.  The default font is somewhat
small to me, so I tried:

(add-to-list
 'default-frame-alist
 '(font
   . "-outline-Arial Unicode MS-normal-normal-normal-mono-16-*-*-*-p-*-iso8859-1"))

After that, a new frame got too tall, so I think I still need
a workaround like this:

(defadvice make-frame (after shrink-frame-height activate)
  "Shrink the height of a new frame."
  (sit-for 0)
  (if (> (frame-parameter ad-return-value 'height) 30)
      (modify-frame-parameters ad-return-value '((height . 30)))))

Regards,

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

From: martin rudalics <rudalics <at> gmx.at>
To: Katsumi Yamaoka <yamaoka <at> jpl.org>
Cc: 25511 <at> debbugs.gnu.org
Subject: Re: bug#25511: 26.0.50; modify-frame-parameters modifies undesignated
 parameter?
Date: Tue, 24 Jan 2017 08:46:04 +0100

> Instead
> of dragging it manually I use:
>
> (defadvice make-frame (after adjust-frame-height-and-position activate)
>    "Shrink the height of a new frame and move it upward."
>    (if (ad-get-arg 0) nil
>      (sit-for 0) ;; Added for new Emacs 26
>      (modify-frame-parameters ad-return-value
>                               '((height . 32) (top . 1112)))))

Why don't you use ‘after-make-frame-functions’?

martin

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

From: martin rudalics <rudalics <at> gmx.at>
To: Katsumi Yamaoka <yamaoka <at> jpl.org>
Cc: 25511 <at> debbugs.gnu.org
Subject: Re: bug#25511: 26.0.50; modify-frame-parameters modifies undesignated
 parameter?
Date: Tue, 24 Jan 2017 08:46:30 +0100

> (make-frame '((left . 0) (top . 0)))
> launches a new frame on the top-left corner of the *lower* screen,
> the position and the size are:
> ((top . 0) (left . 0) (width . 80) (height . 36))
> It varies to
> ((top + -1076) (left + -258) (width . 80) (height . 36))
> after moving it to the top-left corner of the upper screen.
> I feel it a very good behavior.

Does this imply that GTK cannot handle Windows' multiple monitors?  Can
you invoke ‘display-monitor-attributes-list’ for both displays and on
the native and the cygwin builds?

> As for the eclipse of the bottom of an Emacs frame by the task-
> bar, it doesn't happen by default.  However, it seems to be due
> to the size of the default font.  The default font is somewhat
> small to me, so I tried:
>
> (add-to-list
>   'default-frame-alist
>   '(font
>     . "-outline-Arial Unicode MS-normal-normal-normal-mono-16-*-*-*-p-*-iso8859-1"))
>
> After that, a new frame got too tall,

This is a consequence of Emacs' attitude to keep the number of lines of
a frame unchanged when changing a frame's default font size (see the
corresponding calls to adjust_frame_size in x_new_font).  You should be
able to avoid this by setting ‘frame-inhibit-implied-resize’ to t.

> so I think I still need
> a workaround like this:
>
> (defadvice make-frame (after shrink-frame-height activate)
>    "Shrink the height of a new frame."
>    (sit-for 0)
>    (if (> (frame-parameter ad-return-value 'height) 30)
>        (modify-frame-parameters ad-return-value '((height . 30)))))

Then why don't you use 30 lines in the first place?  In any case, you
should be able to get the size of the workarea of any of your displays
via the above mentioned ‘display-monitor-attributes-list’ and, using
‘set-frame-position’ and ‘set-frame-size’, be able to fine-tune the
positioning of your frame in a way that it doesn't overlap the taskbar.

martin

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

From: Katsumi Yamaoka <yamaoka <at> jpl.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 25511 <at> debbugs.gnu.org
Subject: Re: bug#25511: 26.0.50;
 modify-frame-parameters modifies undesignated parameter?
Date: Tue, 24 Jan 2017 18:18:07 +0900

On Tue, 24 Jan 2017 08:46:30 +0100, martin rudalics wrote:
> Does this imply that GTK cannot handle Windows' multiple monitors?  Can
> you invoke ‘display-monitor-attributes-list’ for both displays and on
> the native and the cygwin builds?

Windows native 25.1.90 shows:
(((geometry 0 0 1366 768)
  (workarea 0 0 1366 738)
  (mm-size 344 194)
  (name . "\\\\.\\DISPLAY1") ;; Note PC
  (frames))
 ((geometry -258 -1080 1920 1080)
  (workarea -258 -1080 1920 1050)
  (mm-size 531 299)
  (name . "\\\\.\\DISPLAY2") ;; External display
  (frames #<frame emacs <at> YAMAOKA-PC 04bbd448>)))

26.0.50 built on Cygwin shows:
(((geometry 258 1080 1366 768)
  (workarea 258 1080 1366 768)
  (mm-size 347 195)
  (frames)
  (source . "Gdk"))
 ((geometry 0 0 1920 1080)
  (workarea 0 0 1920 1080)
  (mm-size 488 274)
  (frames #<frame emacs <at> yamaoka-PC 0x77f446a8>)
  (source . "Gdk")))

The values except for `frames' don't vary whether a frame stays
at DISPLAY1 or DISPLAY2.

Thanks for the suggestions about ‘after-make-frame-functions’,
‘frame-inhibit-implied-resize’, and others.  I didn't recall
I've been using ‘after-make-frame-functions’ for the other
purposes. ;-)  I'll try them one by one from now on.  Anyway, I
concluded I should not use dirty codes such as advising the core
functions, as much as possible.

Regards,

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

From: martin rudalics <rudalics <at> gmx.at>
To: Katsumi Yamaoka <yamaoka <at> jpl.org>
Cc: 25511 <at> debbugs.gnu.org
Subject: Re: bug#25511: 26.0.50; modify-frame-parameters modifies undesignated
 parameter?
Date: Tue, 24 Jan 2017 10:37:37 +0100

> Windows native 25.1.90 shows:
> (((geometry 0 0 1366 768)
>    (workarea 0 0 1366 738)
>    (mm-size 344 194)
>    (name . "\\\\.\\DISPLAY1") ;; Note PC
>    (frames))
>   ((geometry -258 -1080 1920 1080)
>    (workarea -258 -1080 1920 1050)
>    (mm-size 531 299)
>    (name . "\\\\.\\DISPLAY2") ;; External display
>    (frames #<frame emacs <at> YAMAOKA-PC 04bbd448>)))
>
> 26.0.50 built on Cygwin shows:
> (((geometry 258 1080 1366 768)
>    (workarea 258 1080 1366 768)
>    (mm-size 347 195)
>    (frames)
>    (source . "Gdk"))
>   ((geometry 0 0 1920 1080)
>    (workarea 0 0 1920 1080)
>    (mm-size 488 274)
>    (frames #<frame emacs <at> yamaoka-PC 0x77f446a8>)
>    (source . "Gdk")))

The workareas' heights differ from the display heights for native
Windows but they don't for Gdk.  So it seems that Gdk might not be able
to deal with the taskbar.  We would have to find out why.

Funnily, the mm-size values differ as well.  God knows why.  If you have
a tape measure around you could find out who's more right ;-)

> The values except for `frames' don't vary whether a frame stays
> at DISPLAY1 or DISPLAY2.
>
> Thanks for the suggestions about ‘after-make-frame-functions’,
> ‘frame-inhibit-implied-resize’, and others.  I didn't recall
> I've been using ‘after-make-frame-functions’ for the other
> purposes. ;-)  I'll try them one by one from now on.  Anyway, I
> concluded I should not use dirty codes such as advising the core
> functions, as much as possible.

Advising is no problem per se.  But ‘after-make-frame-functions’ is
there so it's better to use it (and along the way find out if there are
any problems with it).  Obviously, my proposal to use the workarea won't
work for Cygwin anyway, given you figures above.

martin

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

From: npostavs <at> users.sourceforge.net
To: martin rudalics <rudalics <at> gmx.at>
Cc: 25511 <at> debbugs.gnu.org, Katsumi Yamaoka <yamaoka <at> jpl.org>
Subject: Re: bug#25511: 26.0.50;
 modify-frame-parameters modifies undesignated parameter?
Date: Mon, 05 Jun 2017 08:57:13 -0400

martin rudalics <rudalics <at> gmx.at> writes:

>> Thanks for the suggestions about ‘after-make-frame-functions’,
>> ‘frame-inhibit-implied-resize’, and others.  I didn't recall
>> I've been using ‘after-make-frame-functions’ for the other
>> purposes. ;-)  I'll try them one by one from now on.  Anyway, I
>> concluded I should not use dirty codes such as advising the core
>> functions, as much as possible.
>
> Advising is no problem per se.  But ‘after-make-frame-functions’ is
> there so it's better to use it (and along the way find out if there are
> any problems with it).  Obviously, my proposal to use the workarea won't
> work for Cygwin anyway, given you figures above.

Is there something more to do with this bug?

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

From: martin rudalics <rudalics <at> gmx.at>
To: npostavs <at> users.sourceforge.net
Cc: 25511 <at> debbugs.gnu.org, Katsumi Yamaoka <yamaoka <at> jpl.org>
Subject: Re: bug#25511: 26.0.50; modify-frame-parameters modifies undesignated
 parameter?
Date: Mon, 05 Jun 2017 15:36:17 +0200

> Is there something more to do with this bug?

Is there something more to do with bug#25521?

martin

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

From: npostavs <at> users.sourceforge.net
To: martin rudalics <rudalics <at> gmx.at>
Cc: 25511 <at> debbugs.gnu.org, Katsumi Yamaoka <yamaoka <at> jpl.org>
Subject: Re: bug#25511: 26.0.50;
 modify-frame-parameters modifies undesignated parameter?
Date: Mon, 05 Jun 2017 20:00:15 -0400

martin rudalics <rudalics <at> gmx.at> writes:

>> Is there something more to do with this bug?
>
> Is there something more to do with bug#25521?

Just the question of whether we should add back some delay after frame
creation, the original problem there is easily fixed by changing the
user code.  I gather from your question that it's the same for this bug?

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

From: martin rudalics <rudalics <at> gmx.at>
To: npostavs <at> users.sourceforge.net
Cc: 25511 <at> debbugs.gnu.org, Katsumi Yamaoka <yamaoka <at> jpl.org>
Subject: Re: bug#25511: 26.0.50; modify-frame-parameters modifies undesignated
 parameter?
Date: Tue, 06 Jun 2017 08:38:26 +0200

>>> Is there something more to do with this bug?
>>
>> Is there something more to do with bug#25521?
>
> Just the question of whether we should add back some delay after frame
> creation, the original problem there is easily fixed by changing the
> user code.  I gather from your question that it's the same for this bug?

Yes.  Problems in this area have existed for a long time.  Practically
all of them result from code using ‘make-frame’ followed by code that
immediately tries to read or modify properties of the frame to create.
For example, Bug#25511 has

(let ((frame (make-frame)))
  (modify-frame-parameters frame ...

while Bug#25521 has

  (make-frame '((name . "foo")
                ...
  (select-frame-by-name "foo")

and, for example, Bug#25943 has

  (let  ((simple-frame   (make-frame  `((name       . "Simple Frame")
	 ...
      (unwind-protect
          (while  (progn
                    (set-frame-size  simple-frame ...

IIRC there were more similar reports.  BTW Bug#25943 was reported for an
Emacs 25.1 GTK build hence before you removed the delay to fix Bug#24091.

We could introduce some customizable delay and, whenever a bug in this
area is reported, tell people to increase that delay.  If the bug does
not disappear after the delay has gotten pretty large, we have a more
nasty problem.  Otherwise, we have perfidiously shifted responsibility
to the user.

martin

Previous Next

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