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

Previous Next

Full log

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

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

> Still, if I have "focus stealing prevention" set to None, the Emacs
> frame is raised in both the prompting case and the non-prompting case,
> but the input focus is handled differently in the two cases.  Raising
> the frame but not getting the input focus doesn't seem right to me.

"Focus stealing" is not a well-defined behavior and "preventing" it is
even less so.  It may depend on whether the focus-stealing window was
formerly nonexistent, invisible or iconified and/or whether the window
stems from the same application, executable or process.  Focus may also
depend on whether mouse movement can determine which window gets focus
and whether that window should be raised too when it gets focus.

All this is additionally complicated by the fact that there are no APIs
an application can use to tell which policy has been set up to decide
how it should behave.  But in general, any application's focus stealing
behavior has been set up by the user - compliantly or intentionally.

In particular, we all agree that Emacs may steal focus from itself since
otherwise popping up a second frame would never allow that frame to get
focus immediately.  But we probably are not sure whether running a timer
or reacting to a file notification should make Emacs pop up a new frame
and give it focus - the policy here will depend on the case at hand.

Note also that desktop managers like GNOME shell do not show a taskbar
any more, so they cannot even pulse the icon of the application
requesting focus there as, for example, Windows usually does in such
case.  Finally, Wayland seems to ignore requests to transfer focus in
any case.  So applications may have to change their attitude wrt newer
backends, desktops and user behaviors in order to not fall behind or
even be regarded as hostile.

That said, I agree with Mike when he says that "Raising the frame but
not getting the input focus doesn't seem right to me".  Emacs should try
its best to to not drive the user into such a situation.

martin

Previous Next

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