Re: other-frame, other-window prefix keys

[Stephen Leake]

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