From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alain Knaff Newsgroups: gmane.emacs.bugs Subject: bug#7269: bug #7269: 24.0.50; opening a file via emacsclient -c moves the mouse cursor to, the top left of the frames buffer. Date: Sun, 14 Nov 2010 01:20:49 +0100 Message-ID: <4CDF2B61.90309@knaff.lu> References: <87y69q55un.fsf@yahoo.de> <4CDEF181.6010503@knaff.lu> <4CDEFD4E.1090603@knaff.lu> <4CDF0235.8030301@knaff.lu> <4CDF05BF.7040805@knaff.lu> <4CDF0CD1.3020305@knaff.lu> <4CDF1D54.5020000@knaff.lu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1289695465 9987 80.91.229.12 (14 Nov 2010 00:44:25 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 14 Nov 2010 00:44:25 +0000 (UTC) Cc: 7269@debbugs.gnu.org To: Lennart Borgman Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Nov 14 01:44:20 2010 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PHQhf-0004Hf-Rs for geb-bug-gnu-emacs@m.gmane.org; Sun, 14 Nov 2010 01:44:20 +0100 Original-Received: from localhost ([127.0.0.1]:34533 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PHQhf-0007Sf-3J for geb-bug-gnu-emacs@m.gmane.org; Sat, 13 Nov 2010 19:44:19 -0500 Original-Received: from [140.186.70.92] (port=38084 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PHQhX-0007QL-6P for bug-gnu-emacs@gnu.org; Sat, 13 Nov 2010 19:44:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PHQhO-0007q7-Vk for bug-gnu-emacs@gnu.org; Sat, 13 Nov 2010 19:44:10 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:37021) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PHQhO-0007po-Tz for bug-gnu-emacs@gnu.org; Sat, 13 Nov 2010 19:44:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1PHQHF-000789-JY; Sat, 13 Nov 2010 19:17:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alain Knaff Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 14 Nov 2010 00:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7269 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 7269-submit@debbugs.gnu.org id=B7269.128969376727392 (code B ref 7269); Sun, 14 Nov 2010 00:17:01 +0000 Original-Received: (at 7269) by debbugs.gnu.org; 14 Nov 2010 00:16:07 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PHQGM-00077l-Hc for submit@debbugs.gnu.org; Sat, 13 Nov 2010 19:16:07 -0500 Original-Received: from crmm.lgl.lu ([158.64.72.228] helo=lll.lu) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PHQGJ-00077J-6p for 7269@debbugs.gnu.org; Sat, 13 Nov 2010 19:16:05 -0500 Original-Received: from [188.115.12.243] (ip-188-115-12-243.dyn.luxdsl.pt.lu [188.115.12.243] (may be forged)) by lll.lu (8.14.3/8.14.3/Debian-6) with ESMTP id oAE0Krht005647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Nov 2010 01:20:54 +0100 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Lightning/1.0b1 Thunderbird/3.0.10 In-Reply-To: X-MIME-Autoconverted: from 8bit to quoted-printable by lll.lu id oAE0Krht005647 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sat, 13 Nov 2010 19:17:01 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:41598 Archived-At: On 11/14/2010 12:50 AM, Lennart Borgman wrote: > On Sun, Nov 14, 2010 at 12:20 AM, Alain Knaff wrote: >=20 >>> >>> 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 unsu= re >> what they do exactly, and am (for this discussion...) not overly >> concerned with these. >=20 > I am beeing very imprecise here. What you should distinguish is which > window/application takes the keyboard input and which window is on top > on the screen. (The latter means that it will take mouse input inside > the window.) ok, I see. Yes, in my case I'm more concerned about keyboard input than about which window is on top. >>> 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 initiat= ed >> by the user. >> >> Keyboard input is context sensitive. >=20 > All input is. :-) >> .. 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. >=20 > Yes, but there seem to be different opinions for what this mean. In > many circumstances launching an application means you want to use it > and therefore wants it to have input focus. But not in your use cases > of course. Maybe it's dangerous to make too many assumptions, and preferable to rely on explicit actions rather than second-guessing the user. Maybe the user was just feeling hot? :-) >> So, the app only gets keyboard focus when the user gives it keyboard >> focus. Period. >=20 > Unfortunately that is not clear, see above. Why does this have to feel like a cheesy rape trial? :-) >> Sometimes an application may want to get the user's attention (to info= rm >> 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 thei= r >> outline in the desktop pager, but never to forcefully grab keyboard fo= cus. >=20 > It depends on the window manager what the proper way is. It is > actually specified for some of them. Hopefully there is a standardized API for "get user's attention unintrusively"... [...] >> I'm not really sure what background has to do with it... Background on= ly >> 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 window= s >> these programs may spawn, and what they do with these... >=20 > So this means that this part of the semantic does not apply here. No, not really... > 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"? >>> 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 i= n >> the first place... >=20 > These are good point, but different people and different situations > might require different solutions. However I do not know anything > about what has been done on that level. Somehow, other apps don't feel the need to mess in a similar way with keyboard focus. Now, I understand that it is a windows compatibility thingy. But then, why is this code activated on non-Windows platforms? Wouldn't it be possible to make everybody happy by just bracketing it with #idef w32 ... #endif, or something similar? >=20 >> And the compilation from my example would probably been have started i= n >> the foreground in its shell, in order not to mess up its copious outpu= t... >> >> And why should it be the window manager's job to police apps? >=20 > I think it is about cooperation and some pieces might be missing, see a= bove. 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...) >=20 >>> (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 :-) >=20 > Simple enough ;-) >=20 > But maybe not flexible enough. Well, it's simple enough for the 99% of the other Linux applications out there... >>>> But apparently, there is more than one method to grab focus, and som= e >>>> aren't blocked by this >>> >>> Yes. In some situations the users choice must be overriden. >> >> Which would these be? >=20 > 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? >>> 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 W= 32 >> ... #endif so that they don't bother users of other platforms? >=20 > 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. From my observation, on Linux almost none do. Shouldn't that tell you something? Why does emacs want to be the white elephant her= e? > See above. There > are different solutions and your solution tends to be best for a > programmer, at least it looks so to me. However most users are not > programmers (and maybe that is part of the problem for GNU/Linux that > opinions from programmers does not respect other users needs and > therefore makes the platform unnecessary impopular). We have a saying here in Luxembourg: "Mir w=C3=B6lle bleiwe wat mir sin" = ("We want to stay what we are"). What good is a popular Linux if it has had to sell its soul in order to become so? If I want Windows, I can go out into a shop and buy it right now. I don't need to transform Linux into Windows. If popularity means becoming flaky and unreliable, I prefer to live without it. ... and if you are really concerned about pandering to Windows users that migrated to Linux, then bracket the offending code with if(getenv("WINDOWS_COMPATIBILITY")) { ... } instead. So those users who really want this can set the WINDOWS_COMPATIBILITY environment variable to 1... Hey, maybe we can even get a standard rolling to agree on a same environment variable for all applications that might feel the need to transform Linux into Windows :-) >=20 >> In simpler words: we chose to use Linux because we prefer the way it >> works. Please don't make it behave like Windows :-) >=20 > 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? Alain