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 <lennart.borgman@gmail.com>]

On Sun, Nov 14, 2010 at 1:20 AM, Alain Knaff <alain@knaff.lu> wrote:
>
> Why does this have to feel like a cheesy rape trial? :-)

Not sure ;-)


> Hopefully there is a standardized API for "get user's attention
> unintrusively"...

There is the "always on top" feature for windows.


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


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


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



>> 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 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?
>>
>> Urgent messages.
>
> 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.)


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


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

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


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