Re: History for query replace pairs

[Juri Linkov]

>> I realized right now that the most intuitive and convenient way is
>> to implement a new general function to read two values in the minibuffer
>> with two entry fields.
>
> Where there is two, there is +infinity.

Or more accurately: Where there is one, there is +infinity :)

In case of the minibuffer, this means that we already have
one entry field in the minibuffer, so it makes sense to extend it
to multiple entry fields.

> In other words, why stop at two? Let’s have a general function that
> accepts a description of zero or more parameters (I don’t know, call
> it a “dialog template” or “interactive specification”) and allows the
> user to enter all of them using Customize-like widgets in the
> minibuffer. (Though at this point it probably makes sense to maintain
> both composite histories for each dialog and separate histories for
> each field.)

There are some problems with reading multiple values in the
minibuffer like proposed by Josh.  One problem is what a key to use
to switch to another input field? In Customize-like widgets this is
accomplished by TAB, but in the minibuffer TAB performs completion
(not in query-replace but in completing-read generally).
Customize provides another key M-TAB (M-C-i) for completion.
We could use the same key for multi-value completing-read.