From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: [rudalics@gmx.at: Re: [simon.marshall@misys.com: mouse-autoselect-window needs a de lay]] Date: Sun, 03 Sep 2006 18:37:11 +0200 Message-ID: <85r6ysyki0.fsf@lola.goethe.zz> References: <854pvpym4i.fsf@lola.goethe.zz> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1157301510 17652 80.91.229.2 (3 Sep 2006 16:38:30 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 3 Sep 2006 16:38:30 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 03 18:38:30 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GJuzN-00075i-Cx for ged-emacs-devel@m.gmane.org; Sun, 03 Sep 2006 18:38:29 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GJuzM-000461-QY for ged-emacs-devel@m.gmane.org; Sun, 03 Sep 2006 12:38:28 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GJuz7-000422-Pp for emacs-devel@gnu.org; Sun, 03 Sep 2006 12:38:13 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GJuz7-00040e-40 for emacs-devel@gnu.org; Sun, 03 Sep 2006 12:38:13 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GJuz6-00040B-SZ for emacs-devel@gnu.org; Sun, 03 Sep 2006 12:38:12 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GJv9Q-0002Yl-V1 for emacs-devel@gnu.org; Sun, 03 Sep 2006 12:48:53 -0400 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1GJuyz-0006rI-0C; Sun, 03 Sep 2006 12:38:05 -0400 Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id 7CF941C4D3A4; Sun, 3 Sep 2006 18:37:11 +0200 (CEST) Original-To: rms@gnu.org In-Reply-To: <854pvpym4i.fsf@lola.goethe.zz> (David Kastrup's message of "Sun, 03 Sep 2006 18:02:05 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:59287 Archived-At: David Kastrup writes: > Richard Stallman writes: > >> Would people please comment on this bug fix? >> >> From: martin rudalics Subject: Re: >> [simon.marshall@misys.com: mouse-autoselect-window needs a de lay] > > I think a delay is the wrong thing to do here since it makes stuff > unpredictable. The right fix, in my opinion, would be lazy focus > change: only when a keyboard or mouse event occurs in the new > window, is the focus changed. That has the disadvantage that the > user may be surprised by the change since the old window appears to > have focus before typing a key. > > In order to mitigate the surprise, it might be reasonable to visibly > unfocus the old window (by the different highlighting of the mode > line and the different cursor type), but not refocus a different > window before an event occurs. A different possibility would be to change focus visibly, but when the mouse pointer moves out of the window and, for example, onto toolbar or menu bar, refocus back to the original window if no intervening event occured. This would imply that you could not change focus only by moving the mouse if the first action in the new window was using the toolbar or menu bar. It would also mean quite more flicker than the "just unfocus" variant. Anyway: > I don't think it is reasonable to expect to sort this out before the > release. I think that there are several viable possibilities, and > we'd need the feedback of testers trying each of those out for several > weeks before it would be viable to decide on a sensible strategy. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum