unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Spencer Baugh <sbaugh@janestreet.com>
To: Po Lu <luangruo@yahoo.com>
Cc: 62164@debbugs.gnu.org
Subject: bug#62164: 29.0.60; ediff behaves poorly by default on tiling window managers
Date: Thu, 16 Mar 2023 11:07:21 -0400	[thread overview]
Message-ID: <CAO=BR8PWk3f7F1MsPivKbgoyTnQ7u1giiY0ZG_+Gr58HjbNAVA@mail.gmail.com> (raw)
In-Reply-To: <878rg087v5.fsf@yahoo.com>

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?





  reply	other threads:[~2023-03-16 15:07 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAO=BR8PWk3f7F1MsPivKbgoyTnQ7u1giiY0ZG_+Gr58HjbNAVA@mail.gmail.com' \
    --to=sbaugh@janestreet.com \
    --cc=62164@debbugs.gnu.org \
    --cc=luangruo@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).