bug#25511: 26.0.50; modify-frame-parameters modifies undesignated parameter?

[martin rudalics]

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