* bug#62164: 29.0.60; ediff behaves poorly by default on tiling window managers @ 2023-03-13 16:44 Spencer Baugh 2023-03-14 0:59 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-03-14 13:13 ` Phil Sainty 0 siblings, 2 replies; 22+ messages in thread From: Spencer Baugh @ 2023-03-13 16:44 UTC (permalink / raw) To: 62164 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)) ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#62164: 29.0.60; ediff behaves poorly by default on tiling window managers 2023-03-13 16:44 bug#62164: 29.0.60; ediff behaves poorly by default on tiling window managers Spencer Baugh @ 2023-03-14 0:59 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-03-14 1:00 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-03-14 3:06 ` Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-03-14 13:13 ` Phil Sainty 1 sibling, 2 replies; 22+ messages in thread From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-03-14 0:59 UTC (permalink / raw) To: Spencer Baugh; +Cc: 62164 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#62164: 29.0.60; ediff behaves poorly by default on tiling window managers 2023-03-14 0:59 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-03-14 1:00 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-03-16 15:07 ` Spencer Baugh 2023-03-14 3:06 ` Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors 1 sibling, 1 reply; 22+ messages in thread From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-03-14 1:00 UTC (permalink / raw) To: Spencer Baugh; +Cc: 62164 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#62164: 29.0.60; ediff behaves poorly by default on tiling window managers 2023-03-14 1:00 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-03-16 15:07 ` Spencer Baugh 2023-03-17 1:56 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 1 reply; 22+ messages in thread From: Spencer Baugh @ 2023-03-16 15:07 UTC (permalink / raw) To: Po Lu; +Cc: 62164 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? ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#62164: 29.0.60; ediff behaves poorly by default on tiling window managers 2023-03-16 15:07 ` Spencer Baugh @ 2023-03-17 1:56 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-04-02 1:53 ` sbaugh 0 siblings, 1 reply; 22+ messages in thread From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-03-17 1:56 UTC (permalink / raw) To: Spencer Baugh; +Cc: 62164 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#62164: 29.0.60; ediff behaves poorly by default on tiling window managers 2023-03-17 1:56 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-04-02 1:53 ` sbaugh 2023-04-02 5:55 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 1 reply; 22+ messages in thread From: sbaugh @ 2023-04-02 1:53 UTC (permalink / raw) To: Po Lu; +Cc: Spencer Baugh, 62164 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 -- ^ permalink raw reply related [flat|nested] 22+ messages in thread
* bug#62164: 29.0.60; ediff behaves poorly by default on tiling window managers 2023-04-02 1:53 ` sbaugh @ 2023-04-02 5:55 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-04-02 11:33 ` sbaugh 0 siblings, 1 reply; 22+ messages in thread From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-04-02 5:55 UTC (permalink / raw) To: sbaugh; +Cc: Spencer Baugh, 62164 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#62164: 29.0.60; ediff behaves poorly by default on tiling window managers 2023-04-02 5:55 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-04-02 11:33 ` sbaugh 2023-05-09 18:27 ` Spencer Baugh 0 siblings, 1 reply; 22+ messages in thread From: sbaugh @ 2023-04-02 11:33 UTC (permalink / raw) To: Po Lu; +Cc: Spencer Baugh, 62164 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#62164: 29.0.60; ediff behaves poorly by default on tiling window managers 2023-04-02 11:33 ` sbaugh @ 2023-05-09 18:27 ` Spencer Baugh 2023-05-09 19:15 ` Eli Zaretskii 0 siblings, 1 reply; 22+ messages in thread From: Spencer Baugh @ 2023-05-09 18:27 UTC (permalink / raw) To: sbaugh; +Cc: Po Lu, 62164 [-- 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 ^ permalink raw reply related [flat|nested] 22+ messages in thread
* bug#62164: 29.0.60; ediff behaves poorly by default on tiling window managers 2023-05-09 18:27 ` Spencer Baugh @ 2023-05-09 19:15 ` Eli Zaretskii 2023-06-05 21:56 ` Spencer Baugh 0 siblings, 1 reply; 22+ messages in thread From: Eli Zaretskii @ 2023-05-09 19:15 UTC (permalink / raw) To: Spencer Baugh; +Cc: luangruo, sbaugh, 62164 > 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#62164: 29.0.60; ediff behaves poorly by default on tiling window managers 2023-05-09 19:15 ` Eli Zaretskii @ 2023-06-05 21:56 ` Spencer Baugh 2023-06-05 23:51 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-06-06 11:29 ` Eli Zaretskii 0 siblings, 2 replies; 22+ messages in thread From: Spencer Baugh @ 2023-06-05 21:56 UTC (permalink / raw) To: Eli Zaretskii; +Cc: luangruo, sbaugh, 62164 [-- 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 ^ permalink raw reply related [flat|nested] 22+ messages in thread
* bug#62164: 29.0.60; ediff behaves poorly by default on tiling window managers 2023-06-05 21:56 ` Spencer Baugh @ 2023-06-05 23:51 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-06-06 11:29 ` Eli Zaretskii 1 sibling, 0 replies; 22+ messages in thread From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-06-05 23:51 UTC (permalink / raw) To: Spencer Baugh; +Cc: sbaugh, Eli Zaretskii, 62164 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#62164: 29.0.60; ediff behaves poorly by default on tiling window managers 2023-06-05 21:56 ` Spencer Baugh 2023-06-05 23:51 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-06-06 11:29 ` Eli Zaretskii 2023-06-28 1:13 ` Spencer Baugh 1 sibling, 1 reply; 22+ messages in thread From: Eli Zaretskii @ 2023-06-06 11:29 UTC (permalink / raw) To: Spencer Baugh; +Cc: luangruo, sbaugh, 62164 > 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#62164: 29.0.60; ediff behaves poorly by default on tiling window managers 2023-06-06 11:29 ` Eli Zaretskii @ 2023-06-28 1:13 ` Spencer Baugh 2023-06-28 1:25 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-06-28 11:56 ` Eli Zaretskii 0 siblings, 2 replies; 22+ messages in thread From: Spencer Baugh @ 2023-06-28 1:13 UTC (permalink / raw) To: Eli Zaretskii; +Cc: luangruo, sbaugh, 62164 [-- 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 ^ permalink raw reply related [flat|nested] 22+ messages in thread
* bug#62164: 29.0.60; ediff behaves poorly by default on tiling window managers 2023-06-28 1:13 ` Spencer Baugh @ 2023-06-28 1:25 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-06-28 11:56 ` Eli Zaretskii 1 sibling, 0 replies; 22+ messages in thread From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-06-28 1:25 UTC (permalink / raw) To: Spencer Baugh; +Cc: sbaugh, Eli Zaretskii, 62164 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#62164: 29.0.60; ediff behaves poorly by default on tiling window managers 2023-06-28 1:13 ` Spencer Baugh 2023-06-28 1:25 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-06-28 11:56 ` Eli Zaretskii 2023-06-28 12:55 ` Spencer Baugh 1 sibling, 1 reply; 22+ messages in thread From: Eli Zaretskii @ 2023-06-28 11:56 UTC (permalink / raw) To: Spencer Baugh; +Cc: luangruo, sbaugh, 62164 > 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#62164: 29.0.60; ediff behaves poorly by default on tiling window managers 2023-06-28 11:56 ` Eli Zaretskii @ 2023-06-28 12:55 ` Spencer Baugh 2023-06-28 13:40 ` Robert Pluim 0 siblings, 1 reply; 22+ messages in thread From: Spencer Baugh @ 2023-06-28 12:55 UTC (permalink / raw) To: Eli Zaretskii; +Cc: luangruo, sbaugh, 62164 [-- 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 ^ permalink raw reply related [flat|nested] 22+ messages in thread
* bug#62164: 29.0.60; ediff behaves poorly by default on tiling window managers 2023-06-28 12:55 ` Spencer Baugh @ 2023-06-28 13:40 ` Robert Pluim 2023-07-03 19:21 ` sbaugh 0 siblings, 1 reply; 22+ messages in thread From: Robert Pluim @ 2023-06-28 13:40 UTC (permalink / raw) To: Spencer Baugh; +Cc: luangruo, sbaugh, Eli Zaretskii, 62164 >>>>> 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 -- ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#62164: 29.0.60; ediff behaves poorly by default on tiling window managers 2023-06-28 13:40 ` Robert Pluim @ 2023-07-03 19:21 ` sbaugh 2023-07-06 7:51 ` Eli Zaretskii 0 siblings, 1 reply; 22+ messages in thread From: sbaugh @ 2023-07-03 19:21 UTC (permalink / raw) To: Robert Pluim; +Cc: luangruo, Spencer Baugh, Eli Zaretskii, 62164 [-- 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 ^ permalink raw reply related [flat|nested] 22+ messages in thread
* bug#62164: 29.0.60; ediff behaves poorly by default on tiling window managers 2023-07-03 19:21 ` sbaugh @ 2023-07-06 7:51 ` Eli Zaretskii 0 siblings, 0 replies; 22+ messages in thread From: Eli Zaretskii @ 2023-07-06 7:51 UTC (permalink / raw) To: sbaugh; +Cc: luangruo, sbaugh, rpluim, 62164-done > 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#62164: 29.0.60; ediff behaves poorly by default on tiling window managers 2023-03-14 0:59 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-03-14 1:00 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-03-14 3:06 ` Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors 1 sibling, 0 replies; 22+ messages in thread From: Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-03-14 3:06 UTC (permalink / raw) To: Po Lu; +Cc: sbaugh, 62164 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#62164: 29.0.60; ediff behaves poorly by default on tiling window managers 2023-03-13 16:44 bug#62164: 29.0.60; ediff behaves poorly by default on tiling window managers Spencer Baugh 2023-03-14 0:59 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-03-14 13:13 ` Phil Sainty 1 sibling, 0 replies; 22+ messages in thread From: Phil Sainty @ 2023-03-14 13:13 UTC (permalink / raw) To: 62164 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2023-07-06 7:51 UTC | newest] Thread overview: 22+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-03-13 16:44 bug#62164: 29.0.60; ediff behaves poorly by default on tiling window managers Spencer Baugh 2023-03-14 0:59 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-03-14 1:00 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-03-16 15:07 ` Spencer Baugh 2023-03-17 1:56 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-04-02 1:53 ` sbaugh 2023-04-02 5:55 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-04-02 11:33 ` sbaugh 2023-05-09 18:27 ` Spencer Baugh 2023-05-09 19:15 ` Eli Zaretskii 2023-06-05 21:56 ` Spencer Baugh 2023-06-05 23:51 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-06-06 11:29 ` Eli Zaretskii 2023-06-28 1:13 ` Spencer Baugh 2023-06-28 1:25 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-06-28 11:56 ` Eli Zaretskii 2023-06-28 12:55 ` Spencer Baugh 2023-06-28 13:40 ` Robert Pluim 2023-07-03 19:21 ` sbaugh 2023-07-06 7:51 ` Eli Zaretskii 2023-03-14 3:06 ` Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-03-14 13:13 ` Phil Sainty
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).