From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: Usage examples of dedicated windows and popup frames? Date: Sat, 9 Jul 2011 08:03:31 -0700 Message-ID: References: <871uy0n9ch.fsf@member.fsf.org> <8762nc8xqe.fsf@member.fsf.org> <4E185100.2050100@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1310223854 12100 80.91.229.12 (9 Jul 2011 15:04:14 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 9 Jul 2011 15:04:14 +0000 (UTC) Cc: 'Tassilo Horn' , emacs-devel@gnu.org To: "'martin rudalics'" , "'Stefan Monnier'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 09 17:04:10 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QfZ4g-0004Lo-NF for ged-emacs-devel@m.gmane.org; Sat, 09 Jul 2011 17:04:06 +0200 Original-Received: from localhost ([::1]:57060 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QfZ4f-0005wX-Dd for ged-emacs-devel@m.gmane.org; Sat, 09 Jul 2011 11:04:05 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:56838) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QfZ4R-0005wQ-Cp for emacs-devel@gnu.org; Sat, 09 Jul 2011 11:03:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QfZ4Q-0007w1-7I for emacs-devel@gnu.org; Sat, 09 Jul 2011 11:03:51 -0400 Original-Received: from acsinet15.oracle.com ([141.146.126.227]:49732) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QfZ4Q-0007vx-15 for emacs-devel@gnu.org; Sat, 09 Jul 2011 11:03:50 -0400 Original-Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p69F3jJx018538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 9 Jul 2011 15:03:47 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p69F3hb0000098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Jul 2011 15:03:44 GMT Original-Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p69F3c4D008918; Sat, 9 Jul 2011 10:03:38 -0500 Original-Received: from dradamslap1 (/10.159.36.198) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 09 Jul 2011 08:03:37 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4E185100.2050100@gmx.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Thread-Index: Acw+OEj0rKfOtgkiRrmAonfeRBa4cQACmt4g X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090209.4E186DD3.009F:SCFSTAT5015188, ss=1, re=-4.000, fgs=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) X-Received-From: 141.146.126.227 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:141854 Archived-At: > >> 1. Goto *scratch* and eval the form above. > >> 2. (def ==> a comletion frame pops up *and gets input focus* > > > > This input focus issue is a problem, indeed, but AFAIK > > it's one that's difficult to fix. > > Drew uses `redirect-frame-focus' and from what I can tell after > experimenting a bit with his code it seems to work. Yes, but I do that explicitly as part of my setup, and only for the `*Completions*' frame. I know ahead of time that Emacs will use buffer `*Completions*', and I know that its input focus should be redirected to the minibuffer frame (by default). But as I mentioned, there are occasionally some other frames that pop up in a context where the focus should remain in the minibuffer. In my case, buffers named `*...*' are special-display (dedicated), so they pop up in separate frames. Only rarely is such a buffer used as part of a dialog, but it can happen, breaking the necessary input focus. Some such pop-up frames are in fact for completion. Some vanilla and 3rd-party Emacs code uses completion with a buffer other than `*Completions*'. Nothing inherently wrong with that, but it thus steps outside my workaround of redirecting the `*Completions*' frame focus to the minibuffer frame. For instance, after `M-e' in Isearch, `M-TAB' completes, and if there is more than one candidate then it pops up buffer `*Isearch completions*' (not `*Completions*'). Since that buffer name matches my `special-display-regexps', it gets a separate, dedicated frame. And when the new frame is created Windows gives it the focus, taking the focus away from the minibuffer frame. Without some extra, workaround coding for such a case the user needs to click the minibuffer frame to get the focus back where it belongs. And obviously a user cannot really special-code or customize to deal with each such pop-up frame that might arise. Nothing prevents a library (vanilla or otherwise) from popping up a buffer whose name matches `special-display-regexps', including for completion or another context where the focus should not move to another frame. And then there's the problem of removing that popped-up frame when the dialog is finished. Similarly, there I can foresee the problem in the case of `*Completions*' and handle it specially (knowing the completion dialog). Not so in the general case (unknown). Again, in practice there are only very few such pop-up dialog frames, other than `*Completions*'. But there is still a general problem, even if it is rare because I've taken care of it for the main case (`*Completions*'). I know that you know all of this already. Just mentioning it to complete the thread info a bit. Perhaps we could add a way for code to indicate that it is displaying a given buffer only for the purpose and duration of a user dialog, and thus: a. For that duration the buffer's frame (if separate) would have its input focus redirected to the minibuffer's frame. b. After the dialog finishes, the buffer's frame (if separate) would be deleted. E.g., something like: (with-dialog-buffer BUF ...) Perhaps something like that could be a way to handle the general case (providing that coders actually used it).