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.

[Lennart Borgman]

On Sat, Nov 13, 2010 at 11:10 PM, Alain Knaff <alain@knaff.lu> wrote:
>>
>> 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.

Having multiple programs open is the idea of Windows I guess (but it
was not invented by MS, it is older).

> 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.

I think you refer to another problem: The sync problem of keyboard
input and window focus. When a new program is launched and it is going
to grab focus it is difficult to sync.

However I would say that the compilation program should not get window
and keyboard focus automatically. There should be a way to avoid it.
And isn't there actually that? Can't you start those programs in the
background from most shells?

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

This is not a GNU/Linux thing.

> However, it could be argued that the window manager should do a better
> job at policing applications.

It would seem natural to me that the window manager respected the
users decision to run a program in the background. (But I do not know
if there is enough semantic/syntax for that for the shells. I simply
no very little about the *nix shells. And I even do not know about
this for the w32 shells.)

> But apparently, there is more than one method to grab focus, and some
> aren't blocked by this

Yes. In some situations the users choice must be overriden. But on w32
there has been many changes to avoid that this is used when it should
not be used. (In the case of emacsclient it should be used.)

>>> 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?


This is over my head. I know nothing about this. But I hope someone
else will look at it.