>> clone-frame does not correctly clone frames on a pixelwise basis.
>>
>> make-frame's text-pixels geometry support does not produce specified
>> pixelwise geometry. This also impacts frameset-restore's ability to
>> precisely reproduce pixelwise frame sizes.
This would be a bug in frameset.el. One problem I see is that
'frame-resize-pixelwise' must be set "very early" when restoring a
session - at least _before_ the first time we send size hints to the
window manager.
The goal is, I think, to achieve pixelwise harmony among clone, make, and restore. FWIW, my GUI sessions always run with frame-resize-pixelwise set to t and see these sizing issues consistently. My reproducer is intended to engender the conversation as an illustration. I have resorted to manual labor to set frame sizes in various places and including squirreling away frame pixel size in frameset-save just to manually reset it after restoration due to text-pixel reliability issues. Somewhere in the bowels of frame.c,
et.al., is an issue where text-pixels behaves differently than set-frame-size which is reliable on NS where make-frame using text-pixels is incorrect by the vertical scroll bar width. GTK it's off, too, but I didn't analyze that further.
>> I consider these to be related as clone-frame's use of make-frame could be
>> using text-pixels but if that doesn't work then pixelwise cloning won't
>> work. I did read through the code base as best as I could but could not
>> find the source of the text-pixels issue.
>>
>> The following reproducer, under -Q, shows the same results on 29.4 and
>> 30.0.92. My main platform is NS and I also did some testing on GTK. GTK's
>> issues seem a bit "messier" and I didn't spend any time trying to
>> understand them in depth as I was more interested to know if GTK worked
>> correctly or not, which it doesn't.
Your code binds 'frame-resize-pixelwise' temporarily. This cannot work
reliably. That variable should never change in an Emacs session because
its value affects the way we send size hint increments to the window
manager.
Again, this is just a reproducer for discussion and is intended to illustrate the issues, not to specifically discuss user habits for frame-resize-pixelwise across a GUI session. I think most people these days probably do have it set to t, even if it's become reflexive.
This is, admittedly, a design error that would have to be fixed as
follows:
- Implement a new frame parameter 'resize-pixelwise'.
I certainly prefer something more explicit such as this.
- Send size hints according to the value of this parameter. When the
parameter is set, new size hints must be sent.
Alternatively, we could send new size hints for all live frames whenever
'frame-resize-pixelwise' is changed. This would have to be done with a
variable watcher. Still, let-binding this variable would confuse the
hell out of our interactions with the window manager. When the scope of
the let-binding is left, we would have to send size hints again.
No, please.
>> This is an implementation of clone-frame that uses text-pixels under
>> make-frame. This depends on make-frame text-pixels being corrected. Happy
>> to supply this as a patch should the discussion of these issues progress in
>> that direction.
>>
>> (defun clone-frame (&optional frame no-windows pixelwise)
What would the WM do in a situation where PIXELWISE is non-nil and
'frame-resize-pixelwise' is nil?
The simple interim code (vs. the resize-pixelwise proposal) respects frame-resize-pixelwise as the user's preference. Same with being explicit by saying 'pixelwise, it's user intention.
(when (and (display-graphic-p frame)
(or pixelwise frame-resize-pixelwise))
FWIW, there are surely weird WM issues but at the very least, we're talking about the inner geometry text-width and text-height that Emacs controls and I stayed away from external geometry to start off at least seeing if we can correct for what Emacs controls completely. GTK is definitely worse than NS but at least in NS every user has the same experience as the WM options and behaviors are more constrained than X11-derived kind of free-for-all WMs.
martin