[-- Attachment #1: Type: text/plain, Size: 4009 bytes --] With emacs -Q use the mouse to drag the bottom edge of your frame up as far as possible. With GTK builds I see menu and tool bar and one line of *scratch*, with a Lucid build only menu and tool bar remain visible. Apparently, Emacs handles such resizing well but under the hood there is one slightly devastating difference: The GTK3 build is not aware of the last resizing steps. Evaluating (frame-height) in the final one line frame yields 4, so Emacs misses three lines. In GTK2 and Lucid we get 3 but this is an Emacs internal issue. If you do (setq window-safe-min-height 0) before dragging the border, you get 1 as expected. You can visualize the difference better by evaluating (setq frame-size-history '(100)) before dragging, evaluating (frame--size-history) when dragging finished and inspecting the buffer *frame-size-history*. Here I get for a GTK2 build (only the lines with <= 144 pixels listed) Frame size history of #<frame *scratch* - GNU Emacs at restno 0x190aac0> xg-frame-resized (720 144 720 126) nil adjust-frame-size-1 (720 144 720 126) (change-frame-size 5) adjust-frame-size-3 (720 144 720 126) (752 144 752 126) xg-frame-resized (720 126 720 108) nil adjust-frame-size-1 (720 126 720 108) (change-frame-size 5) adjust-frame-size-3 (720 126 720 108) (752 126 752 108) xg-frame-resized (720 108 720 90) nil adjust-frame-size-1 (720 108 720 90) (change-frame-size 5) adjust-frame-size-3 (720 108 720 90) (752 108 752 90) xg-frame-resized (720 90 720 72) nil adjust-frame-size-1 (720 90 720 72) (change-frame-size 5) xg-frame-resized (720 90 720 54) nil adjust-frame-size-1 (720 90 720 54) (change-frame-size 5) xg-frame-resized (720 90 720 36) nil adjust-frame-size-1 (720 90 720 36) (change-frame-size 5) xg-frame-resized (720 90 720 18) nil adjust-frame-size-1 (720 90 720 18) (change-frame-size 5) while for a GTK3 build I get Frame size history of #<frame *scratch* - GNU Emacs at restno 0x2e5e6d0> xg-frame-resized (720 144 720 126) nil adjust-frame-size-1 (720 144 720 126) (change-frame-size 5) adjust-frame-size-3 (720 144 720 126) (752 144 752 126) xg-frame-resized (720 126 720 108) nil adjust-frame-size-1 (720 126 720 108) (change-frame-size 5) adjust-frame-size-3 (720 126 720 108) (752 126 752 108) xg-frame-resized (720 108 720 90) nil adjust-frame-size-1 (720 108 720 90) (change-frame-size 5) adjust-frame-size-3 (720 108 720 90) (752 108 752 90) xg-frame-resized (720 90 720 84) nil adjust-frame-size-1 (720 90 720 84) (change-frame-size 5) As you can see, the initial parts of these traces are the same. But when it comes to shrink the frame below a height of 90 pixels, the GTK3 build goes to 84 pixels and stalls there while the GTK2 build continues to receive sizes down to one line (18 pixels). Yet in both cases the WM window shrinks the same way down to one buffer line. We could dismiss this issue as a bug nobody will care about because in practice nobody will notice it. But suppose we wanted to establish some useful minimum frame size bounds like other applications (Thunderbird, Firefox) do and pass them to the window manager. This works fine for all builds but the GTK3 one. There, dragging the frame border ceases again to report the last corresponding values and we get a frame looking like in the attached shot (this is a split frame with two windows). The culprit of the GTK3 behavior is Jan Djärv's fix for Bug#8919 which overrides X11 functions with homemade ones. Commenting out these functions fixes the behavior here. I'm not sure how to proceed though. Reverting Jan's change might break Emacs for KDE users again although I doubt it. A configure option is no option for people who do not build their Emacsen. So a Lisp option is probably the only way to go which means to copy the functions from SetNrmHint.c to emacsgtkfixed.c. Or maybe remove the emacsgtkfixed files altogether? Any ideas? martin [-- Attachment #2: GTK3-frame after dragging bottom border.png --] [-- Type: image/png, Size: 41012 bytes --]
> From: martin rudalics <rudalics@gmx.at>
> Date: Sat, 6 Mar 2021 11:47:39 +0100
>
> The culprit of the GTK3 behavior is Jan Djärv's fix for Bug#8919 which
> overrides X11 functions with homemade ones. Commenting out these
> functions fixes the behavior here. I'm not sure how to proceed though.
>
> Reverting Jan's change might break Emacs for KDE users again although I
> doubt it. A configure option is no option for people who do not build
> their Emacsen. So a Lisp option is probably the only way to go which
> means to copy the functions from SetNrmHint.c to emacsgtkfixed.c. Or
> maybe remove the emacsgtkfixed files altogether? Any ideas?
When Jan made that change, did GTK3 already exist? If not, then we
could avoid using that code for GTK3.
Alternatively, we could disallow making frames smaller than 4 lines,
because making our code jump through hoops for uses cases that are
supposed to be rare, to say the least, makes little sense to me.
[-- Attachment #1: Type: text/plain, Size: 1906 bytes --] > When Jan made that change, did GTK3 already exist? Sure. > If not, then we > could avoid using that code for GTK3. At the time he made the breaking change (June 2011) Jan remarked: "This is so ugly, so maybe Emacs should remove Gtk3 support for this release?" Unfortunately he went on with the change and the chance to get rid of GTK3 was lost forever. BTW, I don't have the faintest idea how that change works in the first place. > Alternatively, we could disallow making frames smaller than 4 lines, > because making our code jump through hoops for uses cases that are > supposed to be rare, to say the least, makes little sense to me. That's what I'm trying to do because you asked for such a solution. It cannot be a fixed number of lines like 4 because minibuffer-only or ediff control frames want less. OTOH four lines are not enough when shrinking a frame with say four windows stacked above each other. Rather, I calculate, from the number of vertically stacked windows, the presence of scroll bars, mode, header and tab bar lines and a plethora of other factors a minimal height of the frame and try to pass that to the window manager. But GTK3 intercepts me. To make this visually more evident: I ask for a minimum height of 11 lines and that information apparently makes it through to the window manager which stops shrinking the window at 11 lines as requested. Somehow though GTK manages to swallow the last three ConfigureNotify events in the way I described in my OP, thus making Emacs think that the frame stopped shrinking at 14 lines. Consequently, our frame resizing mechanism does not try to shrink the normal windows and the minibuffer gets cut off from view as can be seen in what I attach as 11_bad. The expected correct behavior (and the one produced after defining out the XSetWMNormalHints and XSetWMSizeHints redefinitions) is attached as 11_good. martin [-- Attachment #2: 11_bad.png --] [-- Type: image/png, Size: 42924 bytes --] [-- Attachment #3: 11_good.png --] [-- Type: image/png, Size: 50117 bytes --]
> Cc: 46963@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Sat, 6 Mar 2021 20:29:02 +0100
>
> > Alternatively, we could disallow making frames smaller than 4 lines,
> > because making our code jump through hoops for uses cases that are
> > supposed to be rare, to say the least, makes little sense to me.
>
> That's what I'm trying to do because you asked for such a solution. It
> cannot be a fixed number of lines like 4 because minibuffer-only or
> ediff control frames want less. OTOH four lines are not enough when
> shrinking a frame with say four windows stacked above each other.
>
> Rather, I calculate, from the number of vertically stacked windows, the
> presence of scroll bars, mode, header and tab bar lines and a plethora
> of other factors a minimal height of the frame and try to pass that to
> the window manager. But GTK3 intercepts me.
Then perhaps we should document this oddity in PROBLEMS and forget
about it.
> Then perhaps we should document this oddity in PROBLEMS and forget > about it. Actually, providing a run-time option for this was trivial. A PROBLEMS entry is still needed. More fun ahead implementing this on the Windows API via MinTrackSize. martin