Re: other-frame, other-window prefix keys

[Stefan Monnier]

> I agree it would be nice. I think that means redoing all those bindings.
> But that's only about 10, so it's doable.

That's the idea, yes.

> But that doesn't handle third-party additions to the C-x 4/5 prefix
> key maps.

We could handle third party additions made via ctl-x-4-map and
ctl-x-5-map, but indeed, I don't think we can reasonably handle those
made via something like (define-key global-map "\C-x4.." ...).

But I think this amount of breakage is acceptable (especially if can
redirect them to use ctl-x-4-map to be both backward and forward compatible).

> More importantly, there is plenty of code that uses switch-to-buffer

That's a good point.  So we should fix switch-to-buffer to pay attention
to display-buffer-overriding-action.

> I think you meant C-x 8 C-h f;

Right.

> 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.

This is a can of worms.

> 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$

Maybe a better solution is to try and generalize the code used for
(current-)prefix-arg.

>> 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.

I don't really have a good idea how it works either, mind you.
I experimented with it specifically thinking of prefixes like C-x 4, but
there are some non-trivial issues.
I'll try and dig it up,


        Stefan