bug#62164: 29.0.60; ediff behaves poorly by default on tiling window managers

[Po Lu]

Spencer Baugh <sbaugh@janestreet.com> writes:

> On Mon, Mar 13, 2023 at 8:59 PM Po Lu <luangruo@yahoo.com> wrote:
>> Spencer Baugh <sbaugh@janestreet.com> writes:
>> > ediff defaults to a multiframe UI on graphical displays.  If the user is
>> > running a tiling window manager on X, the control panel frame gets tiled
>> > and the whole thing becomes either very ugly or unusable.
>> >
>> > This is a very long-standing bug, but it should be fixed.  Most tiling
>> > window manager users work around this with:
>> >
>> > (setq ediff-window-setup-function 'ediff-setup-windows-plain)
>> >
>> > But I would rather the multiframe UI just work correctly by default.
>>
>> Maybe such users could be taught to make the utility window
>> override-redirect instead.
>>
>> > On X, perhaps we should set _NET_WM_WINDOW_TYPE to
>> > _NET_WM_WINDOW_TYPE_UTILITY for the ediff control panel frame, so that
>> > tiling window managers float the control panel frame frame by default.
>> > This would probably need to be a new frame parameter specific to X.  I
>> > can try to make that change if that seems reasonable.  (This would also
>> > be useful for allowing other packages to have multiframe UI modes.)
>>
>> The ediff control frame is not a utility frame because you are supposed
>> to type in it.
>
> When in multi-window mode, Gimp displays its toolbar as a utility
> window, and you are supposed to type in that.  If Gimp does it, surely
> we can do it.

GIMP has been made to work with less window managers than Emacs, simply
by virtue of being much newer.  As a result, users come to expect less
from GIMP than they do from Emacs.

>> One window manager which extensively uses keyboard navigation (I'm not
>> sure I remember which) applies the No Input focus model to
>> _NET_WM_WINDOW_TYPE_UTILITY, not letting you type in such toplevel
>> windows.
>
> Does it do this even if the Input hint is set in WMHints?  If so,
> isn't that window manager just plain broken?  Gimp's toolbar would
> also be broken on that WM.  If Gimp isn't hacking around this broken
> window manager, I don't think we should either.

Here, Emacs isn't ``hacking around'' a broken window manager (and we do
that very often!)  It's simply refraining from using a feature it knows
is buggy.

> (That argument suffices on its own, but as an extra point, keep in
> mind that if this broken WM is a tiling window manager, the ediff
> experience is *already* broken-by-default on that WM)

AFAIK that broken window manager is not a tiling window manager.  I
think it was based on an old version of Openbox.

>> BTW, `x-change-window-property' lets you mess around with window
>> properties if you want.  No frame parameter needed.
>
> AFAICT, my tiling window manager (XMonad) makes its tiling vs floating
> decision when the window is first created, so changing the window
> property after the fact doesn't help.  I assume most tiling window
> managers behave the same.

You can withdraw the window prior to mapping it: see
`make-frame-visible' and `make-frame-invisible'.

Window managers don't care about a window until it is mapped.

> So, we need a new frame parameter so that we can set the window type
> at the time of creating the frame.  Unless there's some existing way
> to set a window property for a new frame at creation time?

You can set it prior to the frame being managed by the window manager,
by creating it with the `visible' frame parameter set to nil, prior to
changing window properties on it.

Anyway, I object to exposing any more EWMH features than we already do
via frame parameters.  The EWMH rarely apply to all window managers, but
since we will document its features as frame parameters, people will use
them, and users of partially compliant or non-compliant window managers
will suffer.  We already have too many: consider the Qfullwidth and
Qfullheight values of the `fullscreen' frame parameter, which are not
only nusiances when people try to use them, but also a porting hazard.