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

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

[Spencer Baugh]

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.

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.)

I'm not sure what we'd do for other windowing systems.  Probably the
only other platform where tiling window managers are at all common is
Wayland; perhaps there's some way to set this hint through PGTK?


In GNU Emacs 29.0.60 (build 3, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.15.12, Xaw scroll bars) of 2023-03-13 built on
 igm-qws-u22796a
Repository revision: e759905d2e0828eac4c8164b09113b40f6899656
Repository branch: emacs-29
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: CentOS Linux 7 (Core)

Configured using:
 'configure --with-x-toolkit=lucid --with-modules
 --with-gif=ifavailable'

Configured features:
CAIRO DBUS FREETYPE GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LIBSELINUX LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND
SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XINPUT2 XPM LUCID
ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: ELisp/d

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils ediff ediff-merg ediff-mult ediff-wind
ediff-diff ediff-help ediff-init ediff-util pp apropos thai-util
thai-word mule-util lao-util enriched disp-table facemenu view savehist
misearch multi-isearch ibuffer ibuffer-loaddefs display-line-numbers
hippie-exp comint ansi-osc ansi-color ring dabbrev saveplace completion
time-date subr-x cl-extra vc-git diff-mode easy-mmode vc-dispatcher
bug-reference find-func shortdoc text-property-search cl-print byte-opt
gv bytecomp byte-compile thingatpt help-fns radix-tree help-mode
cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo x-toolkit
xinput2 x multi-tty make-network-process emacs)

Memory information:
((conses 16 185840 15713)
 (symbols 48 11378 0)
 (strings 32 34965 1522)
 (string-bytes 1 1003016)
 (vectors 16 20776)
 (vector-slots 8 523892 22186)
 (floats 8 131 236)
 (intervals 56 2030 18)
 (buffers 976 20)
 (heap 1024 26111 1190))

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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.

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.

> I'm not sure what we'd do for other windowing systems.  Probably the
> only other platform where tiling window managers are at all common is
> Wayland; perhaps there's some way to set this hint through PGTK?

No, Wayland doesn't provide any of this, unless you use a protocol that
is exclusive to GNOME Shell.  Popups are instead supposed to be
implemented as xdg_popup windows and not xdg_toplevels, or toplevels
transient for another toplevel.  The former is technically infeasible
under GTK, and the latter results in the control frame obscuring
everything else.

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Po Lu <luangruo@yahoo.com> writes:

> 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.
>
> 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.
>
>> I'm not sure what we'd do for other windowing systems.  Probably the
>> only other platform where tiling window managers are at all common is
>> Wayland; perhaps there's some way to set this hint through PGTK?
>
> No, Wayland doesn't provide any of this, unless you use a protocol that
> is exclusive to GNOME Shell.  Popups are instead supposed to be
> implemented as xdg_popup windows and not xdg_toplevels, or toplevels
> transient for another toplevel.  The former is technically infeasible
> under GTK, and the latter results in the control frame obscuring
> everything else.

BTW, `x-change-window-property' lets you mess around with window
properties if you want.  No frame parameter needed.

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

[Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org> writes:

>> ediff defaults to a multiframe UI on graphical displays. [...]
>>
>> [...] perhaps there's some way to set this hint through PGTK?
>
> No, Wayland doesn't provide any of this, unless you use a protocol that
> is exclusive to GNOME Shell.

This is unfortunate.  FTR, I had to configure Sway to make the window
float by default:

--8<---------------cut here---------------start------------->8---
# ediff should always be floating
for_window [title="Ediff"] {
    floating enable
    gap 0
}
--8<---------------cut here---------------end--------------->8---

--
Best,


RY

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

[Phil Sainty]

Spencer Baugh wrote:
> 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)

Myself included -- the default value tends to give me a full-screen
control frame entirely obscuring the original frame, which is very
unhelpful indeed.

That problem aside, I've observed that creating a separate GUI
frame can be *significantly* slower; so for me the plain option
is a win for performance as well as usability.

As `ediff-setup-windows-plain' is the faster and the most reliable
option across differing kinds of windowing systems, I am strongly
in favour of changing the default `ediff-window-setup-function'
value to that.

Users who prefer the separate frame can easily make that change in
their configs easily enough, and improvements to better support a
separate control frame can of course still go ahead.


-Phil

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

[Spencer Baugh]

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.

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

(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)

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

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?

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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.

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

[sbaugh]

Po Lu <luangruo@yahoo.com> writes:
> Spencer Baugh <sbaugh@janestreet.com> writes:
>> On Mon, Mar 13, 2023 at 8:59 PM Po Lu <luangruo@yahoo.com> wrote:
>>> 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.

Thank you for this.  With that I was able to put together this simple
patch which makes the ediff control window float by default on tiling
window managers, or at least on most of them.

What do you think about this patch?  It would be really nice to have
this behavior by default in this way, and I think it would benefit many
users.

diff --git a/lisp/vc/ediff-wind.el b/lisp/vc/ediff-wind.el
index eb903f093f9..1a09bc4225e 100644
--- a/lisp/vc/ediff-wind.el
+++ b/lisp/vc/ediff-wind.el
@@ -948,6 +948,19 @@ ediff-setup-control-frame
     (goto-char (point-min))
 
     (modify-frame-parameters ctl-frame adjusted-parameters)
+    (if (eq window-system 'x)
+      (x-change-window-property
+       "_NET_WM_WINDOW_TYPE"
+       '("_NET_WM_WINDOW_TYPE_UTILITY")
+       ctl-frame
+       "ATOM" 32
+       t)
+      (x-change-window-property
+       "WM_TRANSIENT_FOR"
+       (list (string-to-number (frame-parameter nil 'window-id)))
+       ctl-frame
+       "WINDOW" 32
+       t))
     (make-frame-visible ctl-frame)
 
     ;; This works around a bug in 19.25 and earlier.  There, if frame gets
--

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

sbaugh@catern.com writes:

> Po Lu <luangruo@yahoo.com> writes:
>> Spencer Baugh <sbaugh@janestreet.com> writes:
>>> On Mon, Mar 13, 2023 at 8:59 PM Po Lu <luangruo@yahoo.com> wrote:
>>>> 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.
>
> Thank you for this.  With that I was able to put together this simple
> patch which makes the ediff control window float by default on tiling
> window managers, or at least on most of them.
>
> What do you think about this patch?  It would be really nice to have
> this behavior by default in this way, and I think it would benefit many
> users.
>
> diff --git a/lisp/vc/ediff-wind.el b/lisp/vc/ediff-wind.el
> index eb903f093f9..1a09bc4225e 100644
> --- a/lisp/vc/ediff-wind.el
> +++ b/lisp/vc/ediff-wind.el
> @@ -948,6 +948,19 @@ ediff-setup-control-frame
>      (goto-char (point-min))
>  
>      (modify-frame-parameters ctl-frame adjusted-parameters)
> +    (if (eq window-system 'x)
> +      (x-change-window-property
> +       "_NET_WM_WINDOW_TYPE"
> +       '("_NET_WM_WINDOW_TYPE_UTILITY")
> +       ctl-frame
> +       "ATOM" 32
> +       t)
> +      (x-change-window-property
> +       "WM_TRANSIENT_FOR"
> +       (list (string-to-number (frame-parameter nil 'window-id)))
> +       ctl-frame
> +       "WINDOW" 32
> +       t))
>      (make-frame-visible ctl-frame)
>  
>      ;; This works around a bug in 19.25 and earlier.  There, if frame gets
> --

I think it is fine to make it a user option, but not the default.  BTW,
it is generally The Right Thing to bind `x-fast-protocol-requests' to t
around functions which make X requests when those functions are not
being debugged.

Thanks.

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

[sbaugh]

Po Lu <luangruo@yahoo.com> writes:
> I think it is fine to make it a user option, but not the default.  BTW,
> it is generally The Right Thing to bind `x-fast-protocol-requests' to t
> around functions which make X requests when those functions are not
> being debugged.

Okay, is there any other patch in this direction which you think would
be an acceptable default?

I think you may not realize how universal the (setq
ediff-window-setup-function 'ediff-setup-windows-plain) configuration
is, all because multi-frame ediff behaves poorly on certain window
managers, I've seen it in many different configuration sources.  My
motivation is to make that line of configuration no longer necessary, by
making things work better, if not absolutely right, by default.  Just
replacing it with another bit of configuration is much less satisfying.

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

[Spencer Baugh]

[-- Attachment #1: Type: text/plain, Size: 99 bytes --]


Here's a patch which supports making the control frame into a utility
window with a user option.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Allow-setting-the-ediff-control-frame-as-a-utility-w.patch --]
[-- Type: text/x-patch, Size: 2456 bytes --]

From f23dc72acd370ace6fd934f46e1d6f9a72f943bf Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh@janestreet.com>
Date: Tue, 9 May 2023 14:22:29 -0400
Subject: [PATCH] Allow setting the ediff control frame as a utility window
 under X

This is a step in the direction of making ediff behave better by
default under tiling window managers and fixing bug#62164.

* lisp/vc/ediff-wind.el (ediff-x-utility-control-frame): Add
defcustom.
(ediff-frame-make-utility, ediff-setup-control-frame): Allow setting
the control frame up as a utility window under X. (bug#62164)
---
 lisp/vc/ediff-wind.el | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/lisp/vc/ediff-wind.el b/lisp/vc/ediff-wind.el
index eb903f093f9..9eaed48f16c 100644
--- a/lisp/vc/ediff-wind.el
+++ b/lisp/vc/ediff-wind.el
@@ -69,6 +69,16 @@ ediff-window-setup-function
 		 (function :tag "Other function"))
   :version "24.3")
 
+(defcustom ediff-x-utility-control-frame nil
+  "If non-nil, the control frame is a utility window under X.
+
+This is useful in tiling window managers, where this will cause
+the control frame to be floating rather than tiled.  It should be
+harmless on other well-behaved window managers."
+  :type '(choice (const :tag "Control frame is utility window" t)
+                 (const :tag "Control frame is normal window" nil))
+  :version "30.1")
+
 (ediff-defvar-local ediff-multiframe nil
   "Indicates if we are in a multiframe setup.")
 
@@ -873,6 +883,16 @@ ediff-window-ok-for-display
     (not (ediff-frame-has-dedicated-windows (window-frame wind)))
     )))
 
+(defun ediff-frame-make-utility (frame)
+  (let ((x-fast-protocol-requests t))
+    (x-change-window-property
+     "_NET_WM_WINDOW_TYPE" '("_NET_WM_WINDOW_TYPE_UTILITY")
+     frame "ATOM" 32 t)
+    (x-change-window-property
+     "WM_TRANSIENT_FOR"
+     (list (string-to-number (frame-parameter nil 'window-id)))
+     frame "WINDOW" 32 t)))
+
 ;; Prepare or refresh control frame
 (defun ediff-setup-control-frame (ctl-buffer designated-minibuffer-frame)
   (let ((window-min-height 1)
@@ -948,6 +968,8 @@ ediff-setup-control-frame
     (goto-char (point-min))
 
     (modify-frame-parameters ctl-frame adjusted-parameters)
+    (when (and ediff-x-utility-control-frame (eq window-system 'x))
+      (ediff-frame-make-utility ctl-frame))
     (make-frame-visible ctl-frame)
 
     ;; This works around a bug in 19.25 and earlier.  There, if frame gets
-- 
2.30.2

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

[Eli Zaretskii]

> Cc: Po Lu <luangruo@yahoo.com>, 62164@debbugs.gnu.org
> From: Spencer Baugh <sbaugh@janestreet.com>
> Date: Tue, 09 May 2023 14:27:11 -0400
> 
> +(defcustom ediff-x-utility-control-frame nil
> +  "If non-nil, the control frame is a utility window under X.
> +
> +This is useful in tiling window managers, where this will cause
> +the control frame to be floating rather than tiled.  It should be
> +harmless on other well-behaved window managers."

If this option causes the control frame to be floating rather than
tiled, the name of the option should reflect that.  Using "utility" in
the name of the variable makes the option less self-explanatory,
because that technical terms is not relevant on the user level.

Thanks.

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

[Spencer Baugh]

[-- Attachment #1: Type: text/plain, Size: 820 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:
>> Cc: Po Lu <luangruo@yahoo.com>, 62164@debbugs.gnu.org
>> From: Spencer Baugh <sbaugh@janestreet.com>
>> Date: Tue, 09 May 2023 14:27:11 -0400
>> 
>> +(defcustom ediff-x-utility-control-frame nil
>> +  "If non-nil, the control frame is a utility window under X.
>> +
>> +This is useful in tiling window managers, where this will cause
>> +the control frame to be floating rather than tiled.  It should be
>> +harmless on other well-behaved window managers."
>
> If this option causes the control frame to be floating rather than
> tiled, the name of the option should reflect that.  Using "utility" in
> the name of the variable makes the option less self-explanatory,
> because that technical terms is not relevant on the user level.
>
> Thanks.

Agreed. Revised patch attached:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Allow-setting-the-ediff-control-frame-as-a-utility-w.patch --]
[-- Type: text/x-patch, Size: 2458 bytes --]

From 8725b7376b3e6ddaaa4389d363bd9da56bf3eedb Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh@janestreet.com>
Date: Tue, 9 May 2023 14:22:29 -0400
Subject: [PATCH] Allow setting the ediff control frame as a utility window
 under X

This is a step in the direction of making ediff behave better by
default under tiling window managers and fixing bug#62164.

* lisp/vc/ediff-wind.el (ediff-x-utility-control-frame): Add
defcustom.
(ediff-frame-make-utility, ediff-setup-control-frame): Allow setting
the control frame up as a utility window under X. (bug#62164)
---
 lisp/vc/ediff-wind.el | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/lisp/vc/ediff-wind.el b/lisp/vc/ediff-wind.el
index eb903f093f9..e50df599a98 100644
--- a/lisp/vc/ediff-wind.el
+++ b/lisp/vc/ediff-wind.el
@@ -69,6 +69,16 @@ ediff-window-setup-function
 		 (function :tag "Other function"))
   :version "24.3")
 
+(defcustom ediff-x-floating-control-frame nil
+  "If non-nil, the control frame is a utility window under X.
+
+This is useful in tiling window managers, where this will cause
+the control frame to be floating rather than tiled.  It should be
+harmless on other well-behaved window managers."
+  :type '(choice (const :tag "Control frame is utility window" t)
+                 (const :tag "Control frame is normal window" nil))
+  :version "30.1")
+
 (ediff-defvar-local ediff-multiframe nil
   "Indicates if we are in a multiframe setup.")
 
@@ -873,6 +883,16 @@ ediff-window-ok-for-display
     (not (ediff-frame-has-dedicated-windows (window-frame wind)))
     )))
 
+(defun ediff-frame-make-utility (frame)
+  (let ((x-fast-protocol-requests t))
+    (x-change-window-property
+     "_NET_WM_WINDOW_TYPE" '("_NET_WM_WINDOW_TYPE_UTILITY")
+     frame "ATOM" 32 t)
+    (x-change-window-property
+     "WM_TRANSIENT_FOR"
+     (list (string-to-number (frame-parameter nil 'window-id)))
+     frame "WINDOW" 32 t)))
+
 ;; Prepare or refresh control frame
 (defun ediff-setup-control-frame (ctl-buffer designated-minibuffer-frame)
   (let ((window-min-height 1)
@@ -948,6 +968,8 @@ ediff-setup-control-frame
     (goto-char (point-min))
 
     (modify-frame-parameters ctl-frame adjusted-parameters)
+    (when (and ediff-x-floating-control-frame (eq window-system 'x))
+      (ediff-frame-make-utility ctl-frame))
     (make-frame-visible ctl-frame)
 
     ;; This works around a bug in 19.25 and earlier.  There, if frame gets
-- 
2.39.3

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Spencer Baugh <sbaugh@janestreet.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>>> Cc: Po Lu <luangruo@yahoo.com>, 62164@debbugs.gnu.org
>>> From: Spencer Baugh <sbaugh@janestreet.com>
>>> Date: Tue, 09 May 2023 14:27:11 -0400
>>> 
>>> +(defcustom ediff-x-utility-control-frame nil
>>> +  "If non-nil, the control frame is a utility window under X.
>>> +
>>> +This is useful in tiling window managers, where this will cause
>>> +the control frame to be floating rather than tiled.  It should be
>>> +harmless on other well-behaved window managers."
>>
>> If this option causes the control frame to be floating rather than
>> tiled, the name of the option should reflect that.  Using "utility" in
>> the name of the variable makes the option less self-explanatory,
>> because that technical terms is not relevant on the user level.
>>
>> Thanks.
>
> Agreed. Revised patch attached:
>
> From 8725b7376b3e6ddaaa4389d363bd9da56bf3eedb Mon Sep 17 00:00:00 2001
> From: Spencer Baugh <sbaugh@janestreet.com>
> Date: Tue, 9 May 2023 14:22:29 -0400
> Subject: [PATCH] Allow setting the ediff control frame as a utility window
>  under X
>
> This is a step in the direction of making ediff behave better by
> default under tiling window managers and fixing bug#62164.
>
> * lisp/vc/ediff-wind.el (ediff-x-utility-control-frame): Add
> defcustom.
> (ediff-frame-make-utility, ediff-setup-control-frame): Allow setting
> the control frame up as a utility window under X. (bug#62164)
> ---
>  lisp/vc/ediff-wind.el | 22 ++++++++++++++++++++++
>  1 file changed, 22 insertions(+)
>
> diff --git a/lisp/vc/ediff-wind.el b/lisp/vc/ediff-wind.el
> index eb903f093f9..e50df599a98 100644
> --- a/lisp/vc/ediff-wind.el
> +++ b/lisp/vc/ediff-wind.el
> @@ -69,6 +69,16 @@ ediff-window-setup-function
>  		 (function :tag "Other function"))
>    :version "24.3")
>  
> +(defcustom ediff-x-floating-control-frame nil

I don't think this is correct.  Ordering the control frame above other
windows is one policy taken towards utility windows, but other window
managers may behave differently (by placing the utility window at a
fixed position, for instance.)

The name of this variable should not depend on the behavior of the
window manager.

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

[Eli Zaretskii]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Cc: luangruo@yahoo.com,  sbaugh@catern.com,  62164@debbugs.gnu.org
> Date: Mon, 05 Jun 2023 17:56:38 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> >> Cc: Po Lu <luangruo@yahoo.com>, 62164@debbugs.gnu.org
> >> From: Spencer Baugh <sbaugh@janestreet.com>
> >> Date: Tue, 09 May 2023 14:27:11 -0400
> >> 
> >> +(defcustom ediff-x-utility-control-frame nil
> >> +  "If non-nil, the control frame is a utility window under X.
> >> +
> >> +This is useful in tiling window managers, where this will cause
> >> +the control frame to be floating rather than tiled.  It should be
> >> +harmless on other well-behaved window managers."
> >
> > If this option causes the control frame to be floating rather than
> > tiled, the name of the option should reflect that.  Using "utility" in
> > the name of the variable makes the option less self-explanatory,
> > because that technical terms is not relevant on the user level.
> >
> > Thanks.
> 
> Agreed. Revised patch attached:

Thanks, but I think the first line of the doc string should also be
modified to explain better what the option does.  The rest of the doc
string could then mention "utility window", if doing so will help
someone to understand what happens and why.  But the first line should
be a concise summary, because the various apropos commands show only
that one line.

>      (modify-frame-parameters ctl-frame adjusted-parameters)
> +    (when (and ediff-x-floating-control-frame (eq window-system 'x))
> +      (ediff-frame-make-utility ctl-frame))       ^^^^^^^^^^^^^

I think it is better to use window-system the function here, since
you are talking about a specific frame.

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

[Spencer Baugh]

[-- Attachment #1: Type: text/plain, Size: 2250 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: Spencer Baugh <sbaugh@janestreet.com>
>> Cc: luangruo@yahoo.com,  sbaugh@catern.com,  62164@debbugs.gnu.org
>> Date: Mon, 05 Jun 2023 17:56:38 -0400
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> >> Cc: Po Lu <luangruo@yahoo.com>, 62164@debbugs.gnu.org
>> >> From: Spencer Baugh <sbaugh@janestreet.com>
>> >> Date: Tue, 09 May 2023 14:27:11 -0400
>> >> 
>> >> +(defcustom ediff-x-utility-control-frame nil
>> >> +  "If non-nil, the control frame is a utility window under X.
>> >> +
>> >> +This is useful in tiling window managers, where this will cause
>> >> +the control frame to be floating rather than tiled.  It should be
>> >> +harmless on other well-behaved window managers."
>> >
>> > If this option causes the control frame to be floating rather than
>> > tiled, the name of the option should reflect that.  Using "utility" in
>> > the name of the variable makes the option less self-explanatory,
>> > because that technical terms is not relevant on the user level.
>> >
>> > Thanks.
>> 
>> Agreed. Revised patch attached:
>
> Thanks, but I think the first line of the doc string should also be
> modified to explain better what the option does.  The rest of the doc
> string could then mention "utility window", if doing so will help
> someone to understand what happens and why.  But the first line should
> be a concise summary, because the various apropos commands show only
> that one line.
>
>>      (modify-frame-parameters ctl-frame adjusted-parameters)
>> +    (when (and ediff-x-floating-control-frame (eq window-system 'x))
>> +      (ediff-frame-make-utility ctl-frame))       ^^^^^^^^^^^^^
>
> I think it is better to use window-system the function here, since
> you are talking about a specific frame.

OK, revised patch attached.

I don't know how to name the variable to incorporate both you and Po's
feedback.  The name of the variable can either include "utility" to
describe its implementation, or include "floating" to describe its
effect on most window managers.  (Or include neither, and describe
nothing, which seems worse.)

I personally prefer your variable name, since I still don't know of any
window managers that don't float utility windows, but I don't care much.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Allow-setting-the-ediff-control-frame-as-a-utility-w.patch --]
[-- Type: text/x-patch, Size: 2513 bytes --]

From b8f893709f914b483997791507ee2db888bb9279 Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh@janestreet.com>
Date: Tue, 9 May 2023 14:22:29 -0400
Subject: [PATCH] Allow setting the ediff control frame as a utility window
 under X

This is a step in the direction of making ediff behave better by
default under tiling window managers and fixing bug#62164.

* lisp/vc/ediff-wind.el (ediff-x-utility-control-frame): Add
defcustom.
(ediff-frame-make-utility, ediff-setup-control-frame): Allow setting
the control frame up as a utility window under X. (bug#62164)
---
 lisp/vc/ediff-wind.el | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/lisp/vc/ediff-wind.el b/lisp/vc/ediff-wind.el
index eb903f093f9..7471c5f0fd3 100644
--- a/lisp/vc/ediff-wind.el
+++ b/lisp/vc/ediff-wind.el
@@ -69,6 +69,17 @@ ediff-window-setup-function
 		 (function :tag "Other function"))
   :version "24.3")
 
+(defcustom ediff-x-floating-control-frame nil
+  "If non-nil, the control frame will float under most X WMs.
+
+The control frame will be give the window type \"utility\".  On
+most tiling window managers, this will cause the control frame to
+be floating rather than tiled.  It should be harmless on other
+well-behaved window managers."
+  :type '(choice (const :tag "Control frame floats" t)
+                 (const :tag "Control frame has default WM behavior" nil))
+  :version "30.1")
+
 (ediff-defvar-local ediff-multiframe nil
   "Indicates if we are in a multiframe setup.")
 
@@ -873,6 +884,16 @@ ediff-window-ok-for-display
     (not (ediff-frame-has-dedicated-windows (window-frame wind)))
     )))
 
+(defun ediff-frame-make-utility (frame)
+  (let ((x-fast-protocol-requests t))
+    (x-change-window-property
+     "_NET_WM_WINDOW_TYPE" '("_NET_WM_WINDOW_TYPE_UTILITY")
+     frame "ATOM" 32 t)
+    (x-change-window-property
+     "WM_TRANSIENT_FOR"
+     (list (string-to-number (frame-parameter nil 'window-id)))
+     frame "WINDOW" 32 t)))
+
 ;; Prepare or refresh control frame
 (defun ediff-setup-control-frame (ctl-buffer designated-minibuffer-frame)
   (let ((window-min-height 1)
@@ -948,6 +969,8 @@ ediff-setup-control-frame
     (goto-char (point-min))
 
     (modify-frame-parameters ctl-frame adjusted-parameters)
+    (when (and ediff-x-floating-control-frame (eq (window-system ctl-frame) 'x))
+      (ediff-frame-make-utility ctl-frame))
     (make-frame-visible ctl-frame)
 
     ;; This works around a bug in 19.25 and earlier.  There, if frame gets
-- 
2.39.3

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Spencer Baugh <sbaugh@janestreet.com> writes:

> I don't know how to name the variable to incorporate both you and Po's
> feedback.  The name of the variable can either include "utility" to
> describe its implementation, or include "floating" to describe its
> effect on most window managers.  (Or include neither, and describe
> nothing, which seems worse.)
>
> I personally prefer your variable name, since I still don't know of any
> window managers that don't float utility windows, but I don't care much.

Dtwm.  Or any window manager that doesn't really support the EWMH, for
that matter.  I would simply suggest:

(defun ediff-make-control-frame-utility-window nil
  "If non-nil, make the Ediff control frame a ``utility window''.

Most X window managers will then order the control frame above all other
windows as long as it remains visible.")

I strongly object to Emacs trying to document behavior that is actually
defined by individual window managers, because we will receive
complaints from users about Emacs not behaving as expected, when in fact
it is their window manager that behaves differently.

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

[Eli Zaretskii]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Cc: luangruo@yahoo.com,  sbaugh@catern.com,  62164@debbugs.gnu.org
> Date: Tue, 27 Jun 2023 21:13:09 -0400
> 
> * lisp/vc/ediff-wind.el (ediff-x-utility-control-frame): Add
> defcustom.               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Copy/pasta, right?

> +(defcustom ediff-x-floating-control-frame nil

A better name is ediff-floating-control-frame.

> +  "If non-nil, the control frame will float under most X WMs.
> +
> +The control frame will be give the window type \"utility\".  On
> +most tiling window managers, this will cause the control frame to
> +be floating rather than tiled.  It should be harmless on other
> +well-behaved window managers."

I would document this slightly differently:

    If not-nil, try making the control frame be floating rather than tiled.

  If your X window manager makes the Ediff control frame a tiled one,
  set this to a non-nil value, and Emacs will try to make it floating.
  This only has effect on X displays.

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

[Spencer Baugh]

[-- Attachment #1: Type: text/plain, Size: 1095 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Spencer Baugh <sbaugh@janestreet.com>
>> Cc: luangruo@yahoo.com,  sbaugh@catern.com,  62164@debbugs.gnu.org
>> Date: Tue, 27 Jun 2023 21:13:09 -0400
>> 
>> * lisp/vc/ediff-wind.el (ediff-x-utility-control-frame): Add
>> defcustom.               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Copy/pasta, right?
>
>> +(defcustom ediff-x-floating-control-frame nil
>
> A better name is ediff-floating-control-frame.
>
>> +  "If non-nil, the control frame will float under most X WMs.
>> +
>> +The control frame will be give the window type \"utility\".  On
>> +most tiling window managers, this will cause the control frame to
>> +be floating rather than tiled.  It should be harmless on other
>> +well-behaved window managers."
>
> I would document this slightly differently:
>
>     If not-nil, try making the control frame be floating rather than tiled.
>
>   If your X window manager makes the Ediff control frame a tiled one,
>   set this to a non-nil value, and Emacs will try to make it floating.
>   This only has effect on X displays.

OK, fixed these:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Allow-floating-the-ediff-control-frame-under-X.patch --]
[-- Type: text/x-patch, Size: 2449 bytes --]

From 5aea062fee4f265be146fd7df730ab077b31bb82 Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh@janestreet.com>
Date: Tue, 9 May 2023 14:22:29 -0400
Subject: [PATCH] Allow floating the ediff control frame under X

This is a step in the direction of making ediff behave better by
default under tiling window managers and fixing bug#62164.

* lisp/vc/ediff-wind.el (ediff-floating-control-frame): Add
defcustom.
(ediff-frame-make-utility, ediff-setup-control-frame): Allow setting
the control frame up as a utility window under X. (bug#62164)
---
 lisp/vc/ediff-wind.el | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/lisp/vc/ediff-wind.el b/lisp/vc/ediff-wind.el
index eb903f093f9..74e0e1f9b9f 100644
--- a/lisp/vc/ediff-wind.el
+++ b/lisp/vc/ediff-wind.el
@@ -69,6 +69,16 @@ ediff-window-setup-function
 		 (function :tag "Other function"))
   :version "24.3")
 
+(defcustom ediff-floating-control-frame nil
+  "If not-nil, try making the control frame be floating rather than tiled.
+
+If your X window manager makes the Ediff control frame a tiled one,
+set this to a non-nil value, and Emacs will try to make it floating.
+This only has effect on X displays."
+  :type '(choice (const :tag "Control frame floats" t)
+                 (const :tag "Control frame has default WM behavior" nil))
+  :version "30.1")
+
 (ediff-defvar-local ediff-multiframe nil
   "Indicates if we are in a multiframe setup.")
 
@@ -873,6 +883,16 @@ ediff-window-ok-for-display
     (not (ediff-frame-has-dedicated-windows (window-frame wind)))
     )))
 
+(defun ediff-frame-make-utility (frame)
+  (let ((x-fast-protocol-requests t))
+    (x-change-window-property
+     "_NET_WM_WINDOW_TYPE" '("_NET_WM_WINDOW_TYPE_UTILITY")
+     frame "ATOM" 32 t)
+    (x-change-window-property
+     "WM_TRANSIENT_FOR"
+     (list (string-to-number (frame-parameter nil 'window-id)))
+     frame "WINDOW" 32 t)))
+
 ;; Prepare or refresh control frame
 (defun ediff-setup-control-frame (ctl-buffer designated-minibuffer-frame)
   (let ((window-min-height 1)
@@ -948,6 +968,8 @@ ediff-setup-control-frame
     (goto-char (point-min))
 
     (modify-frame-parameters ctl-frame adjusted-parameters)
+    (when (and ediff-floating-control-frame (eq (window-system ctl-frame) 'x))
+      (ediff-frame-make-utility ctl-frame))
     (make-frame-visible ctl-frame)
 
     ;; This works around a bug in 19.25 and earlier.  There, if frame gets
-- 
2.39.3

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

[Robert Pluim]

>>>>> On Wed, 28 Jun 2023 08:55:13 -0400, Spencer Baugh <sbaugh@janestreet.com> said:

    Spencer> * lisp/vc/ediff-wind.el (ediff-floating-control-frame): Add
    Spencer> defcustom.
    Spencer> (ediff-frame-make-utility, ediff-setup-control-frame): Allow setting
    Spencer> the control frame up as a utility window under X. (bug#62164)

Two spaces after full stop. And I think the convention is to
capitalize 'Bug', but we donʼt follow that very consistently.

I think the new user option warrants an entry in etc/NEWS

    Spencer> ---
    Spencer>  lisp/vc/ediff-wind.el | 22 ++++++++++++++++++++++
    Spencer>  1 file changed, 22 insertions(+)

    Spencer> diff --git a/lisp/vc/ediff-wind.el b/lisp/vc/ediff-wind.el
    Spencer> index eb903f093f9..74e0e1f9b9f 100644
    Spencer> --- a/lisp/vc/ediff-wind.el
    Spencer> +++ b/lisp/vc/ediff-wind.el
    Spencer> @@ -69,6 +69,16 @@ ediff-window-setup-function
    Spencer>  		 (function :tag "Other function"))
    Spencer>    :version "24.3")
 
    Spencer> +(defcustom ediff-floating-control-frame nil
    Spencer> +  "If not-nil, try making the control frame be floating rather than tiled.
    Spencer> +

Style: the description of the option should state the action that
follows from a non-nil value:

"Whether to request a floating control frame rather than a tiled one."

Robert
-- 

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

[sbaugh]

[-- Attachment #1: Type: text/plain, Size: 1840 bytes --]

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Wed, 28 Jun 2023 08:55:13 -0400, Spencer Baugh <sbaugh@janestreet.com> said:
>
>     Spencer> * lisp/vc/ediff-wind.el (ediff-floating-control-frame): Add
>     Spencer> defcustom.
>     Spencer> (ediff-frame-make-utility, ediff-setup-control-frame): Allow setting
>     Spencer> the control frame up as a utility window under X. (bug#62164)
>
> Two spaces after full stop. And I think the convention is to
> capitalize 'Bug', but we donʼt follow that very consistently.
>
> I think the new user option warrants an entry in etc/NEWS

Added, patch at the end.

>     Spencer> ---
>     Spencer>  lisp/vc/ediff-wind.el | 22 ++++++++++++++++++++++
>     Spencer>  1 file changed, 22 insertions(+)
>
>     Spencer> diff --git a/lisp/vc/ediff-wind.el b/lisp/vc/ediff-wind.el
>     Spencer> index eb903f093f9..74e0e1f9b9f 100644
>     Spencer> --- a/lisp/vc/ediff-wind.el
>     Spencer> +++ b/lisp/vc/ediff-wind.el
>     Spencer> @@ -69,6 +69,16 @@ ediff-window-setup-function
>     Spencer>  		 (function :tag "Other function"))
>     Spencer>    :version "24.3")
>  
>     Spencer> +(defcustom ediff-floating-control-frame nil
>     Spencer> +  "If not-nil, try making the control frame be floating rather than tiled.
>     Spencer> +
>
> Style: the description of the option should state the action that
> follows from a non-nil value:
>
> "Whether to request a floating control frame rather than a tiled one."

No, this is correct style, see (info "(elisp) Documentation Tips")

   • The documentation string for a variable that is a yes-or-no flag
     should start with words such as “Non-nil means”, to make it clear
     that all non-‘nil’ values are equivalent and indicate explicitly
     what ‘nil’ and non-‘nil’ mean.



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Allow-floating-the-ediff-control-frame-under-X.patch --]
[-- Type: text/x-patch, Size: 3213 bytes --]

From 6b347e419898ade96f459ddec9f1fda8d7dfef84 Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh@catern.com>
Date: Fri, 7 Apr 2023 17:54:06 -0400
Subject: [PATCH] Allow floating the ediff control frame under X

This is a step in the direction of making ediff behave better by
default under tiling window managers and fixing Bug#62164.

* lisp/vc/ediff-wind.el (ediff-floating-control-frame): Add
defcustom.
(ediff-frame-make-utility, ediff-setup-control-frame): Allow setting
the control frame up as a utility window under X.  (Bug#62164)
---
 etc/NEWS              | 11 +++++++++++
 lisp/vc/ediff-wind.el | 22 ++++++++++++++++++++++
 2 files changed, 33 insertions(+)

diff --git a/etc/NEWS b/etc/NEWS
index 9e6f0c16bcd..9c99cf6c725 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -2314,6 +2314,17 @@ your mail user agent.  The behavior of 'vc-prepare-patch' can be
 modified by the user options 'vc-prepare-patches-separately' and
 'vc-default-patch-addressee'.
 
+** Ediff
+
+---
+*** New user option 'ediff-floating-control-frame'.
+If non-nil, try making the control frame be floating rather than tiled.
+
+Many X tiling window managers make the Ediff control frame a tiled
+window equal in size to the main Emacs frame, which works poorly.
+This option is useful to set if you use such a window manager, and
+will be harmless (or helpful) on most other modern window managers.
+
 ** Message
 
 ---
diff --git a/lisp/vc/ediff-wind.el b/lisp/vc/ediff-wind.el
index eb903f093f9..3077c562d63 100644
--- a/lisp/vc/ediff-wind.el
+++ b/lisp/vc/ediff-wind.el
@@ -69,6 +69,16 @@ ediff-window-setup-function
 		 (function :tag "Other function"))
   :version "24.3")
 
+(defcustom ediff-floating-control-frame nil
+  "If non-nil, try making the control frame be floating rather than tiled.
+
+If your X window manager makes the Ediff control frame a tiled one,
+set this to a non-nil value, and Emacs will try to make it floating.
+This only has effect on X displays."
+  :type '(choice (const :tag "Control frame floats" t)
+                 (const :tag "Control frame has default WM behavior" nil))
+  :version "30.1")
+
 (ediff-defvar-local ediff-multiframe nil
   "Indicates if we are in a multiframe setup.")
 
@@ -873,6 +883,16 @@ ediff-window-ok-for-display
     (not (ediff-frame-has-dedicated-windows (window-frame wind)))
     )))
 
+(defun ediff-frame-make-utility (frame)
+  (let ((x-fast-protocol-requests t))
+    (x-change-window-property
+     "_NET_WM_WINDOW_TYPE" '("_NET_WM_WINDOW_TYPE_UTILITY")
+     frame "ATOM" 32 t)
+    (x-change-window-property
+     "WM_TRANSIENT_FOR"
+     (list (string-to-number (frame-parameter nil 'window-id)))
+     frame "WINDOW" 32 t)))
+
 ;; Prepare or refresh control frame
 (defun ediff-setup-control-frame (ctl-buffer designated-minibuffer-frame)
   (let ((window-min-height 1)
@@ -948,6 +968,8 @@ ediff-setup-control-frame
     (goto-char (point-min))
 
     (modify-frame-parameters ctl-frame adjusted-parameters)
+    (when (and ediff-floating-control-frame (eq (window-system ctl-frame) 'x))
+      (ediff-frame-make-utility ctl-frame))
     (make-frame-visible ctl-frame)
 
     ;; This works around a bug in 19.25 and earlier.  There, if frame gets
-- 
2.41.0

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

[Eli Zaretskii]

> From: sbaugh@catern.com
> Date: Mon, 03 Jul 2023 19:21:53 +0000 (UTC)
> Cc: Spencer Baugh <sbaugh@janestreet.com>, luangruo@yahoo.com, Eli Zaretskii
> 	<eliz@gnu.org>, 62164@debbugs.gnu.org
> 
> > I think the new user option warrants an entry in etc/NEWS
> 
> Added, patch at the end.
> 
> >     Spencer> ---
> >     Spencer>  lisp/vc/ediff-wind.el | 22 ++++++++++++++++++++++
> >     Spencer>  1 file changed, 22 insertions(+)
> >
> >     Spencer> diff --git a/lisp/vc/ediff-wind.el b/lisp/vc/ediff-wind.el
> >     Spencer> index eb903f093f9..74e0e1f9b9f 100644
> >     Spencer> --- a/lisp/vc/ediff-wind.el
> >     Spencer> +++ b/lisp/vc/ediff-wind.el
> >     Spencer> @@ -69,6 +69,16 @@ ediff-window-setup-function
> >     Spencer>  		 (function :tag "Other function"))
> >     Spencer>    :version "24.3")
> >  
> >     Spencer> +(defcustom ediff-floating-control-frame nil
> >     Spencer> +  "If not-nil, try making the control frame be floating rather than tiled.
> >     Spencer> +
> >
> > Style: the description of the option should state the action that
> > follows from a non-nil value:
> >
> > "Whether to request a floating control frame rather than a tiled one."
> 
> No, this is correct style, see (info "(elisp) Documentation Tips")
> 
>    • The documentation string for a variable that is a yes-or-no flag
>      should start with words such as “Non-nil means”, to make it clear
>      that all non-‘nil’ values are equivalent and indicate explicitly
>      what ‘nil’ and non-‘nil’ mean.

Thanks, installed on master, and closing the bug.