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

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

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

[Mathias Dahl]

On 7/1/07, Drew Adams <drew.adams@oracle.com> wrote:
> 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))

We could also allow a function as argument, then you could implement
whatever kind of strange source of input history you wanted. Maybe
that could be done for the "save back" variable argument you proposed.

Just an idea.

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

[Richard Stallman]

    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?

I don't like this.  It is creeping featurism, and not very useful.

If you want to do some special history munging, you can use your own
variable and bind it yourself.  And afterward, if it has been changed,
you can record that change back in the "permanent" history lists however
you wish.

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

[Juri Linkov]

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

A very easy way to achieve this is following:

(let* ((history-add-new-input nil)
       (history (append hi-lock-regexp-history regexp-history))
       (str (read-string "Prompt: " nil 'history)))
  (add-to-history 'hi-lock-regexp-history str))

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

[Drew Adams]

> > 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))
>
> A very easy way to achieve this is following:
>
> (let* ((history-add-new-input nil)
>        (history (append hi-lock-regexp-history regexp-history))
>        (str (read-string "Prompt: " nil 'history)))
>   (add-to-history 'hi-lock-regexp-history str))

Sure. But that's hardly as readable. My proposal was to build that into the
read functions (but without the extraneous addition of the input to the
temporary history variable). Anyway, Richard has nixed the idea.

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

[Davis Herring]

>> A very easy way to achieve this is following:
>>
>> (let* ((history-add-new-input nil)
>>        (history (append hi-lock-regexp-history regexp-history))
>>        (str (read-string "Prompt: " nil 'history)))
>>   (add-to-history 'hi-lock-regexp-history str))
>
> Sure. But that's hardly as readable. My proposal was to build that into
> the
> read functions (but without the extraneous addition of the input to the
> temporary history variable). Anyway, Richard has nixed the idea.

That's what the history-add-new-input -> nil is for.  I don't think that
it's really less readable than

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

(as your #2 option would have it) since the latter offers no hint as to
why three "...-history" words are present.  If it's just the length that
bothers you, one can write

(let ((history (append hi-lock-regexp-history regexp-history)))
   (add-to-history 'hi-lock-regexp-history
                   (read-string "Prompt: " nil 'history)))

and just let the extra append get GCed.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.