GNU bug report logs - #50743
Emacsclient not tested vs. Local Variables prompt

Previous Next

Full log

Message #133 received at 50743 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Jean Louis <bugs <at> gnu.support>
Cc: larsi <at> gnus.org, mkupfer <at> alum.berkeley.edu, psainty <at> orcon.net.nz,
 jidanni <at> jidanni.org, 50743 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#50743: Emacsclient not tested vs. Local Variables prompt
Date: Mon, 27 Sep 2021 19:15:39 +0200

> I think you should leave to Window Manager's configuration however
> user wants it.

Traditionally, we don't do that and I doubt we will as long as X is our
major workhorse.  We have a sufficient number of bug reports asking us
to make Emacs tell the WM where and how to position its top-level
windows.  Maybe things will change when the pgtk branch has found its
way into master.

> Let me give you examples:
>
> - sometimes, I do have a single window (tracking issues) on the top,
>    and other windows appearing on the bottom, that is called in IceWM
>    "Focus always on top", so whatever else appears it will appear under
>    that window.

Literally, "Focus always on top" means that the window that has focus is
on top of the Z-order and vice versa.  This means that you can never
type into a window that is not on top - which is the default behavior of
most window managers.  So if you have chosen that option, you cannot
possibly type into a window "partially appearing under the window on top
of it" as described below.  Right?

> - all the time I use mouse based focus, the window under the mouse has
>    focus, and nothing else;

Providing mouse based focus is an arcane art.  xfwm here for example
takes it too literally so when I have two maximized windows, demaximize
the one on top and the mouse cursor is not over the region covered by
the demaximized window, the window below gets focus.  Similar issues may
happen when creating or deleting windows.  Good mouse based focus means
to keep the mouse on the window that has focus until the user manually
moves the mouse and wait for a customizable period for the mouse to rest
in some area before selecting another window.  I've never seen a WM that
does it all right.

> - all the time I don't use window raising under the mouse, if window
>    has the focus, I don't want raising it automatically; often I
>    overlap windows and do something with it, while I write in the
>    window below partially appearing under the window on top of it;

The issue we discuss here is that the window that has focus is obscured
by a window displaying a prompt either completely or at least in the
area where the user is typing.  While some users may handle that without
moving any of the participating windows, let's not assume that everybody
is able to do that.

martin

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.