From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Leake Newsgroups: gmane.emacs.devel Subject: Re: other-frame, other-window prefix keys Date: Sun, 09 Aug 2015 01:06:10 -0500 Message-ID: <86k2t50ze5.fsf@stephe-leake.org> References: <86vbcq2qgc.fsf@stephe-leake.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1439100414 11058 80.91.229.3 (9 Aug 2015 06:06:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 9 Aug 2015 06:06:54 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 09 08:06:43 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZOJko-0003Cy-Ii for ged-emacs-devel@m.gmane.org; Sun, 09 Aug 2015 08:06:42 +0200 Original-Received: from localhost ([::1]:54461 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZOJkn-0001Ao-M7 for ged-emacs-devel@m.gmane.org; Sun, 09 Aug 2015 02:06:41 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55415) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZOJkZ-00019N-F2 for emacs-devel@gnu.org; Sun, 09 Aug 2015 02:06:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZOJkW-000701-6U for emacs-devel@gnu.org; Sun, 09 Aug 2015 02:06:27 -0400 Original-Received: from gproxy4-pub.mail.unifiedlayer.com ([69.89.23.142]:57673) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1ZOJkV-0006zl-Vj for emacs-devel@gnu.org; Sun, 09 Aug 2015 02:06:24 -0400 Original-Received: (qmail 10739 invoked by uid 0); 9 Aug 2015 06:06:20 -0000 Original-Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy4.mail.unifiedlayer.com with SMTP; 9 Aug 2015 06:06:20 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by cmgw3 with id 2c6E1r00S2UdiVW01c6H1i; Sun, 09 Aug 2015 06:06:19 -0600 X-Authority-Analysis: v=2.1 cv=Qc314Krv c=1 sm=1 tr=0 a=CQdxDb2CKd3SRg4I0/XZPQ==:117 a=CQdxDb2CKd3SRg4I0/XZPQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=9i_RQKNPAAAA:8 a=y7kgw_RnJtkA:10 a=hEr_IkYJT6EA:10 a=x_XPkuGwIRMA:10 a=uRRa74qj2VoA:10 a=0CZJN7T6zoH6X3GBHy0A:9 Original-Received: from [76.218.37.33] (port=49263 helo=TAKVER2) by host114.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZOJkN-0006gf-Ip for emacs-devel@gnu.org; Sun, 09 Aug 2015 00:06:15 -0600 In-Reply-To: (Stefan Monnier's message of "Sat, 08 Aug 2015 16:52:16 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (windows-nt) X-Identified-User: {2442:host114.hostmonster.com:stephele:stephe-leake.org} {sentby:smtp auth 76.218.37.33 authed with stephen_leake@stephe-leake.org} X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 69.89.23.142 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:188632 Archived-At: Stefan Monnier writes: >> C-x 7 causes a buffer displayed by to appear in >> another window in the same frame; a window is created if necessary. >> >> C-x 8 causes a buffer displayed by to appear in >> another frame; a frame is created if necessary. > > It'd be great if you could bind them to C-x 4 and C-x 5 and arrange for > C-x 4 f (and friends) to still work as before. I agree it would be nice. I think that means redoing all those bindings. But that's only about 10, so it's doable. But that doesn't handle third-party additions to the C-x 4/5 prefix key maps. > That would make the advice on switch-to-buffer unnecessary, I think > since C-x 4 b and C-x 5 b would be more handy than C-x 4 C-x C-b > anyway. Well, I don't use C-x 4 etc (and I never have); I use M-m and M-M, bound to ofw-other-window-argument and ofw-other-frame-argument. More importantly, there is plenty of code that uses switch-to-buffer that does _not_ provide C-x 4 bindings, or even -other-window, -other-frame variants. That's the main point of this package; to make it unnecessary to define those variants in the first place. The other-frame, other-window keys must be easy to type to be useful, so we could consider preempting one of the meta-letter keys for this. >> Advising temp-buffer-window-show-advice addresses the issue of how >> temporary prompt buffers are displayed. > > Indeed, this is a bit ugly. Doesn't it prevent C-x 5 C-h f from > displaying the help in a separate frame? That key sequence pops up *Help* for "Global Bindings Starting With C-x 5" (in emacs -Q). So no, the advice is not what makes that not work :). I think you meant C-x 8 C-h f; indeed, that is not shown in another frame. But the next command that displays a buffer is shown in another frame, which is _very_ surprising :). I would argue that `describe-function' should not be using temp-buffer-window-show; the *Help* buffer is _not_ temporary, because it is _not_ automatically closed; it is left to the user to close it. > Maybe we should arrange for the ofw-frame-window-prefix-arg to be > save&restored around calls to read-from-minibuffer. It's not the first > time we have a need for such a thing, so adding a general list of "vars > to save&restore around recursive edits" might be a good idea. That would probably fix other problems, yes. >> There is one issue (see the FIXMEs); if the command is aborted for any >> reason, the prefix (set in ofw-frame-window-prefix-arg) needs to be >> reset. I haven't looked into doing that yet. >> If post-command-hook is run even if a command is aborted, that might be >> a good place to reset this. I'll have to try it. > > Yes, post-command-hook should run even if the command is aborted, IIRC. > But it's also run right after C-x 7 calls ofw-other-window-argument, so > you'd have to be careful to make it survive one post-command-hook. > It's also run for each command executed in the minibuffer (similar > problem to the one for temp-buffer-window-show-advice). Sigh; I knew it would not be simple. Is there an "error-hook" that is run for any error? That would be cleaner. I don't see one in M-x apropos-variable -hook$ >> I'd be happy to put this in GNU ELPA (in part so it is available for >> Emacs 24.3), but there was some discussion in the original thread about >> having something like this in core. > > I think it's OK to put in GNU ELPA for now. Ok > I do hope it can be moved later into core to replace the C-x 4 and C-x > 5 keymaps. Ok. > Regarding experimentation: I'm slightly worried about having > a constantly non-nil display-buffer-overriding-action. So maybe instead > of setting ofw-frame-window-prefix-arg and then interpret this from > a globally-set display-buffer-overriding-action, we could make > ofw-other-window-argument set display-buffer-overriding-action and > dispense with ofw-frame-window-prefix-arg. Yes, that's better. > One other thing: I'd be neat if the echo-area could display the "C-x 7" > prefix if you wait a couple seconds, like it does for C-u. I have some > experimental code around somewhere that moves some of that C-u code from > C so it could be used for C-x 7. Ok, please send the code; I have no idea how that works. -- -- Stephe