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 11:38 PM, Lennart Borgman wrote:
> 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).

Very few things have been invented by MS... :-)

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

I'm concerned about keyboard focus here, i.e. which window gets the
keyboard input events. I vaguely remember having read that there are
other kinds of focus than keyboard focus (window focus?), but I'm unsure
what they do exactly, and am (for this discussion...) not overly
concerned with these.

> When a new program is launched and it is going
> to grab focus it is difficult to sync.

I think this is exactly the reason why focus changes should be initiated
by the user.

Keyboard input is context sensitive. Backspace typed in a shell window
means something else than backspace typed in digikam for example (in one
case, it just erases the last character types, whereas in the other, it
wipes the currently displayed photo...)

Now, if something else than the source of keyboard input changes the
interpretation context (focus), SNAFU results. Hence the rule that all
keyboard focus changes should be initiated (or at least acknowledged) by
the user, who is the source of keyboard input.

However, as acknowledging application-requested keyboard focus is just
as much work as just moving the mouse over to the app to give it
keyboard focus, I think we can do away with that scenario.

So, the app only gets keyboard focus when the user gives it keyboard
focus. Period.

Sometimes an application may want to get the user's attention (to inform
him that they are "done", or that some error condition needs a
decision). The proper way to do this is to flash their border, or their
outline in the desktop pager, but never to forcefully grab keyboard focus.

> 
> However I would say that the compilation program should not get window
> and keyboard focus automatically.

Yes, that's my point. No part of, or program spawned by the compilation
should just grab keyboard focus.

> There should be a way to avoid it.

There is a way to avoid it (keyboard focus stealing prevention), but
wouldn't it be so much better if all programs just behaved nice?

> And isn't there actually that? Can't you start those programs in the
> background from most shells?

I'm not really sure what background has to do with it... Background only
affects which process should get signals if you press Ctrl-C in the
terminal window, it doesn't have anything to do with what other windows
these programs may spawn, and what they do with these...

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

How would the window manager even know which program was in the
background in the general case? Hint: it may not even run on the same
machine. And even in the local case, not all shells may manage
foreground/background in the same way. And in many cases, the
application might not even have been started by an interactive shell in
the first place...

And the compilation from my example would probably been have started in
the foreground in its shell, in order not to mess up its copious output...

And why should it be the window manager's job to police apps? You sound
a little bit like the thief who complains "why aren't there enough
police around to keep me in line". It's your app who plays nasty, please
fix it. And I don't care that in the Middle East (Windows), stealing
might be acceptable behavior, I live in Europe (Linux), and here it this
is definitely  not acceptable :-)

Why can't emacs respect the user's wish to never steal keyboard focus, ever?


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

On Linux, the appropriate behavior would be:

1. If the shell's name ends in sh, then do not let the app forcefully
grab keyboard focus
2. And for those rare shells whose name doesn't end in sh, do not let
the app forcefully grab keyboard focus either :-)

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

Which would these be?

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

Maybe all these Windows specific hacks should be bracketed by #ifdef W32
... #endif so that they don't bother users of other platforms?

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

In simpler words: we chose to use Linux because we prefer the way it
works. Please don't make it behave like Windows :-)

Thanks,

Alain