RE: feature request: indicator of minibuffer-recursion depth

[Drew Adams]

    Regarding the proposal for recursive minibuffer commands to
    quit the outer minibuffer:

1) Are you referring to David R's suggestion to "automatically quit the
command that's occupying the minibuffer whenever another command requires
it"?

David's example was `C-x b' after `C-x C-f'. I think he was suggesting that
`C-x b' should "take over", so that `C-x C-f' is abandoned (analogous to
`C-x b' exiting incremental search). Is that what you mean too?

Also, I believe that David was talking only about the case where
`enable-recursive-minibuffers' is nil. I don't think he suggested to change
the non-nil behavior. Is your "recursive minibuffer commands to quit the
outer minibuffer" also only for the nil case? (I hope so.)


2) Regarding the non-nil case, there is the question of how to handle
exiting the second command (the one that opens a recursive minibuffer).
Currently, no matter how you exit this recursive-minibuffer command (`RET',
`C-g'), you return to the previous level. It can be convenient sometimes for
a command at a deeper minibuffer level to return its result directly to the
top-level command reading minibuffer input - if the recursive-minibuffer
command knows that that is the right thing to do.

For example, an application I have uses recursive minibuffers to provide
additional match patterns for completion. You invoke a command that reads
another pattern in a recursive minibuffer, and that pattern applies to the
existing set of completion candidates, filtering them further. The effect is
cumulative, so there is no logical need to pass the result up the chain of
recursive minibuffers one by one, to return it to the top level.

Instead of requiring the user to exit from each level in turn (passing along
the same result value), I provide a `catch' within (a redefined)
`completing-read' and `read-file-name' to receive the `throw'n result. So,
`RET' effectively chooses a completion candidate for the top-level command.
(`C-g' cancels only a single minibuffer level, as usual.)

This works whenever `completing-read' or `read-file-name' is used, but
whenever `interactive' is used with a literal spec string (e.g. "fFile: ")
the user must still traverse the recursive minibuffer levels one by one.
Since literal `interactive' specs are handled by C code, my Lisp code has no
way to intervene there.

So, how about adding such a `catch' at a lower implementation level, so it
can be used with literal `interactive' specs also? IOW, implement the
equivalent of this change to `completing-read' (where `old-completing-read'
is the built-in `completing-read'), but at a lower level:

 (catch 'read-top
  (old-completing-read prompt table predicate require-match
                       initial-input hist def inherit-input-method)

Of course, most commands, perhaps even most commands that are used to open a
recursive minibuffer, will never `throw' their result here. But those that
want to could.

Just food for thought, for a possible change after the release.