bug#7269: bug #7269: 24.0.50; opening a file via emacsclient -c <file> moves the mouse cursor to, the top left of the frames buffer.

[Alain Knaff]

On 11/13/2010 10:52 PM, Lennart Borgman wrote:
> On Sat, Nov 13, 2010 at 10:40 PM, Alain Knaff <alain@knaff.lu> wrote:
>> On 11/13/2010 10:31 PM, Lennart Borgman wrote:
>> [...]
>>> As I said I know of no exception on w32. All applications I can think
>>> of right now grabs focus when you call them from the command line (or
>>> from Windows Explorer).
>>
>> Ok, but if I really liked this braindead behavior, I'd actually use
>> Windows, rather than Linux. And I'd probably use Notepad too rather than
>> Emacs :-)
> 
> Why is it good that the newly started program does not get focus?

In order not to disrupt the user's work in some other program.
Multitasking may be a foreign concept on Windows, but on Linux, people
routinely have multiple programs open. They may launch a compilation in
one window, and then, while it runs,  launch a firefox for their online
banking. They would be rather unhappy if suddenly their online banking
password would show up readable for all shoulder surfers in the
emacsclient spawned by cvs commit.

Please don't break multitasking, it is one of the many features that we
love about Linux.

> 
>> Maybe, in emacs this behavior could be made conditional on running on
>> Windows?
> 
> Yes. Or the window manager if that is better (and possible).

Only emacs (and firefox/thunderbird in other scenarios) do this. So I
think, the problem is with them, not the window manager.

However, it could be argued that the window manager should do a better
job at policing applications. I've indeed entered such a bug report on
KDE a while back (for the situation caused by firefox/thunderbird), and
their answer was that some elements may have a legitimate need to grab
focus or switch desktops. These elements would be for example the window
manager's own widgets for switching desktops.

However, KDE does have a way of optionally reigning in some of the
methods of stealing focus, this is called "Focus stealing prevention",
and can be found in
systemSettings->WindowBehavior->WindowRules->New->Workarounds

But apparently, there is more than one method to grab focus, and some
aren't blocked by this (... or are only blocked at a price... such as
new windows popping up behind all others rather than in front)

>>> Maybe this is dependent on the window manager used?
>>
>> I use KDE.
>>
>> I don't believe this is a window manager issue... if that was the case,
>> wouldn't all applications behave the same way?
> 
> No. There are some extra difficulties since Emacs uses a server which
> emacsclients connects to.

I've noticed some weirdness there too. Normally, the idea of emacsclient
should be to display the client on the DISPLAY pointed to by the client,
not by the server. Indeed, if I'm logged in over ssh to a remote server,
and start an emacsclient, I want to see that emacsclient on my display,
and not have it displayed on the server's console in some dusty NOC
where it is of use to no-one. Same thing with virtual desktops: I want
to see the emacsclient on the desktop that I am currently on, and not on
the one where emacs' main window is (or worse, have me forcefully
teleported to that desktop).

This was working fine in the old days (> 3 years ago), but some recent
versions do some really bizarre and illogical stuff here. Is this also a
matter of emulating windows? We Linux and Unix users like network
transparency and multiple desktops, please don't break them for us. And
it was working fine for ages before, so why mess with it now?


>>> What happens if you launch a program from the command line without a
>>> file name argument? Does the application get focus?
>>
>> No, of course not.
> 
> Thanks.
> 
>> And this has been the case with other Window managers as well, even
>> before KDE. Even in mwm, twm, fvwm, applications didn't steal focus
>> willy-nilly. I don't know for sure about Gnome, I don't use Gnome very
>> often, but I guess I would have noticed if this was the case...

Thanks,

Alain