RE: Suggestions for the temporary windows used from the minibuffer

[Drew Adams]

        For keys that are bound to commands that manipulate the
        "other" window, bind them instead
        to commands that do the same thing when there is another
        window, but let the user do something else, otherwise?

    The basic idea that these keys could do something else as a
    possibly-useful fallback might be good.  I don't like that specific
    proposal because it is rather complex to use.  I'd rather have something
    that is natural and useful for beginners.

I agree, actually.

If, instead of creating new commands, the existing command definitions were
simply changed to effect an alternative behavior (~ a hook) when there is no
"other" window, then that would simplify the implementation, at least.

If the "hook" (alternative behavior) were null by default, then beginners
would not be affected at all - they would not be aware of the new
possibility. If the "hook" had, instead, a reasonable default behavior, then
that could be natural for beginners, although they might not know how to
change the alternative behavior (nor would they need to).

But if the keys have different behavior, depending on whether or not there
is an "other" window, that in itself could be confusing to beginners - I
think that's your point. One solution is that mentioned above: the
alternative behavior would be null, by default - that is natural for
beginners, but it is no more useful to them than the current behavior.

How else to make it natural for the same keys to have different behavior,
depending on the circumstances? Use a mode: the presence of an "other"
window would manifest a different mode (minor). Modes are not 100% natural
to beginners, but they are fairly common in Emacs.

But of course the existence or absence of an "other" window is not the usual
way of toggling a minor mode - that could be confusing.

Confusion could be minimized if the alternative commands were complementary
in their use to the current commands, in some way. For example, if they only
made sense when there is no "other" window, then no one would mistakenly use
one when trying to use the other. However, I can't think of any commands
that make sense only when there is no "other" window.

Anyone have a good idea for this?

If we find no good alternative behavior for beginners, would it hurt to at
least redefine the commands to allow non-beginners to supply alternative
behaviors (e.g. via a quasi-hook)? That is, use a null behavior by default,
but let people supply an alternative.