[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: other-frame, other-window prefix keys
From: |
Stephen Leake |
Subject: |
Re: other-frame, other-window prefix keys |
Date: |
Sun, 09 Aug 2015 01:06:10 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (windows-nt) |
Stefan Monnier <address@hidden> writes:
>> C-x 7 <command> causes a buffer displayed by <command> to appear in
>> another window in the same frame; a window is created if necessary.
>>
>> C-x 8 <command> causes a buffer displayed by <command> 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