let HISTORY arg to read functions be a list of history variables

[Drew Adams]

1. How about letting the HISTORY argument to read functions (e.g.
`read-string') be a list of history variables, in addition to letting it be
a single history variable? The histories would be appended for user
retrieval. The convention for saving the user input could be either that it
is added to only the first history or that it is added to each of the
histories.

Then, for example, you could write this and let users use a regexp from
either history:

(read-string "Regexp: " nil '(hi-lock-regexp-history regexp-history))

Here, `hi-lock-regexp-history' would presumably be more specific to the task
at hand, so it is placed first. Still, the user has access to more general
regexps from `regexp-history'.

This argument form should cohabit OK with the use of a list argument such as
(HISTORY . POS) to indicate a position, since POS cannot be a non-empty
list. Either we would not allow the position to be specified in the case of
multiple histories, or we would allow it only for the first history - e.g.
((hi-lock-regexp-history . 2) regexp-history).


2. Perhaps(?) even better would be to allow a two-element list as history
argumen: (VARS LIST), where VARS is a list of history variables to update
with the user's entered input and LIST is a history list (not a symbol) to
use for inputting.

That is, let the history to use for `M-p' etc. be an actual history list
(not a variable), and specify separately the history variables to be updated
with the user's entered input. This would let you do more than just append
two histories as in #1 - you could combine them in any way, including
filtering them. IOW, separate history-as-input (list of past inputs, for
M-p) from history-as-output (history variables, updated with the new input).