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/14/2010 01:51 AM, Lennart Borgman wrote:
> On Sun, Nov 14, 2010 at 1:20 AM, Alain Knaff <alain@knaff.lu> wrote:
[...]
>> Hopefully there is a standardized API for "get user's attention
>> unintrusively"...
> 
> There is the "always on top" feature for windows.

Strange name ...

>>> I do
>>> not know if there is anything else that can glue things together.
>>> Maybe the semantic has not been specified clearly.
>>
>> Why can't the answer to "when is it allowed to grab focus" simply be
>> "never"?
> 
> Because it would be very inconventient.
> 
> Take for example the case when a user double-clicks on a file in the
> file manager (on w32 it is Windows Explorer). Then the purpose is to
> open it in the associated application, for example a word processor.
> Is there any reason not to give the word processor the focus in this
> case? (Please remember this is a very common use case.)

Yes, same reasons as discussed earlier still apply:
- not re-interpret user's keyboard input in other context
- not disrupt his work

Why do you think launching a word processor should be somehow special?

Remember, word processors are not among the fastest starting programs,
so there is the real possibility that the user quickly checked his mail
or did something else while waiting for it to open up.

In the old days, when computers were slower, people would have a cup of
coffee while waiting for their stuff to come up. Maybe word processors
back then should have opened the CD tray in order to knock off the
coffee cup from the table, to make sure that the user promptly got back
to them when they were finally ready :-)

Maybe, on w32, it is too cumbersome for the user to give an app the
focus, but this is not the case on Linux, so people are rightfully
appalled when you try to second-guess them here.

>> Somehow, other apps don't feel the need to mess in a similar way with
>> keyboard focus.
> 
> Of course Emacs should behave similar to other apps on the platform as
> far as possible. At least in my opinion.

Exactly. Great to see that we finally agree :-)

>> Now, I understand that it is a windows compatibility thingy.
> 
> I am not sure that it is w32 only. I would be very surprised if it was.

Maybe. Maybe not. But it for sure isn't the case on Linux or other
Unices. So please leave these platforms alone with this second guessing.

>>> I think it is about cooperation and some pieces might be missing, see above.
>>
>> Yeah, that's the point. Window manager assume well-behaved (cooperative)
>> apps, but apparently some aren't. Hence the need of "focus stealing
>> prevention" and similar settings, which unfortunately don't always work
>> (either they are ineffective, or have undesirable side-effects...)
> 
> I think the apps can not solve this all by themselves. But looking
> into the possible semantics of this is far beyond what we actually
> talking about now.

But why are the apps even _trying_ to "solve" anything here? In this
case, it's the apps themselves that are the problem. The solution to the
problem is trivial: don't interfere with the focus _at_all_ on those
platforms where this is frowned upon (Linux, Unix, and possibly others)

Other applications don't try to recreate the "windows experience" on
Linux in such a way either. They just display their window, period.

[...]
>> Wouldn't "flashing" the app's outline be more appropriate? Just imagine
>> emacs wanted to display the urgent message "Disk filling up. Is it ok to
>> delete file xyz.abc to make space (y/n)", but the user just started to
>> type "yesterday" into another app?
> 
> In some situations it is not enough. (For example if continuing doing
> something might crash the computer or destroy data.)

Wouldn't just stopping its own processing, flashing its outline, and
then patiently waiting for its turn be enough?

Could you just give me one concrete situation where forcefully
interrupting the user, and possibly misinterpreting the user's random
chattering as the answer to a life-and-death situation would be
acceptable behavior?

But in any case, we are not even talking about exceptional circumstances
here. If not stopped by the window manager, emacsclient does it
_every_single_time_...

>>> I don't think this is a w32 specific problem at all.
>>
>> Well, I think it is. According to you, on Windows, most apps grab focus
>> when launched.
> 
> No. The window manager gives them focus.

So, apps don't NEED to play games, even on w32, as the window manager
does it for them there?! Well in that case, that bunch of code which
creates the mischief can go:

   On Windows it is not needed, and on Linux it is not wanted.

So why exactly is it there?


>> From my observation, on Linux almost none do. Shouldn't
>> that tell you something? Why does emacs want to be the white elephant here?
> 
> I am sure it does not want to be that.

I am glad we finally agree.

Hopefully, whoever is making decisions on these (mis)features sees this
as well :-)

> Did you try changing the option `server-raise-frame' in Emacs?

Yes, this works, thanks for this valuable information. Hopefully it
doesn't have any nasty side-effects... (the strange name worries me
somewhat...)

No, I didn't know about this option yet. Maybe this should also default
to nil, just like the focus-follows-mouse option should? Or a global
switch to switch off all focus and mouse related "bizarreness" altogether?


>>> There are bigger issues than this. The whole platform GNU/Linux exists
>>> because people want a free platform. Whether it should behave like w32
>>> is something that should be evaluated mainly against this.
>>
>> IMHO, solidity, usability and reliability played as big a role in the
>> popularity of Linux (amongst its primary audience) than its freeness (be
>> it as in beer or as in speech). Why do we have to throw away our
>> advantages to pander to the masses?
> 
> I doubt that there actually would be any GNU/Linux if it was only for
> programmers. It is too expensive for that. A lot of people would not
> invest their free time to develop it - and without that the price
> would be too high. It is or could be a treasure.

If there were no programmers, there wouldn't be any GNU/Linux at all.
Think about it. Why do we programmers have to be so self-deprecatingly
masochistic?

And don't be fooled by my initial example of "lengthy compilation". I
could just as well have said "lengthy account consolidation
calculation", "lengthy movie rendering job", or even "slow starting
office productivity app".

Regards,

Alain