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 00:20:52 +0100 Message-ID: <4CDF1D54.5020000@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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1289692086 31539 80.91.229.12 (13 Nov 2010 23:48:06 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 13 Nov 2010 23:48:06 +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 00:48:02 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 1PHPmN-0006Vd-2C for geb-bug-gnu-emacs@m.gmane.org; Sun, 14 Nov 2010 00:48:02 +0100 Original-Received: from localhost ([127.0.0.1]:55553 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PHPm8-000422-4D for geb-bug-gnu-emacs@m.gmane.org; Sat, 13 Nov 2010 18:44:52 -0500 Original-Received: from [140.186.70.92] (port=32881 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PHPln-0003du-8k for bug-gnu-emacs@gnu.org; Sat, 13 Nov 2010 18:44:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PHPlK-00072R-Ui for bug-gnu-emacs@gnu.org; Sat, 13 Nov 2010 18:44:07 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:49903) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PHPlK-00072L-QV for bug-gnu-emacs@gnu.org; Sat, 13 Nov 2010 18:44:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1PHPLC-0006jK-B3; Sat, 13 Nov 2010 18:17:02 -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: Sat, 13 Nov 2010 23:17:02 +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.128969016625856 (code B ref 7269); Sat, 13 Nov 2010 23:17:02 +0000 Original-Received: (at 7269) by debbugs.gnu.org; 13 Nov 2010 23:16:06 +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 1PHPKI-0006iz-0J for submit@debbugs.gnu.org; Sat, 13 Nov 2010 18:16:06 -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 1PHPKE-0006iZ-Tr for 7269@debbugs.gnu.org; Sat, 13 Nov 2010 18:16:04 -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 oADNKq2p001488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Nov 2010 00: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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sat, 13 Nov 2010 18:17:02 -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:41595 Archived-At: On 11/13/2010 11:38 PM, Lennart Borgman wrote: > On Sat, Nov 13, 2010 at 11:10 PM, Alain Knaff 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