bug#38317: Buffer-local variables don't work as history for read-from-minibuffer

[Federico Tedin]

> I haven't tested the code, but it makes sense to me.  I do wonder
> whether there are any instances of the variables that are local to the
> minibuffer...  but I guess that's unlikely?

I agree that it would be unlikely. I am not sure what the use-case for
having a history local to the minibuffer itself would be. It makes much
more sense for the history to be global or to be determined by the
context i.e. the current buffer (like I want to do with `goto-line').

>> +** 'read-from-minibuffer' now works with buffer-local history variables
>> +The HIST argument of 'read-from-minibuffer' now works correctly with
>> +buffer-local variables. This means that different buffers can have
>> +their own separated input history list if desired.
>
> This should probably be documented in the manual, too?
>
> The patch otherwise looks good to me.

Thanks. In what part of the manual would you document this? I was
thinking of either in:

1) The "Minibuffer History" section (but it doesn't mention the actual
HIST variable anywhere in there, though, and never mentions any specific
minibuffer-reading function)

2) In "Reading Text Strings with the Minibuffer", in the entry for
`read-from-minibuffer' (right before the link to "Minibuffer
History"). Maybe if we add it there users can then infer that other
minibuffer commands with a HIST argument also accept buffer-local
values.

Should I update the docstring for `read-from-minibuffer' as well? I
would like to add two things: that the value can be buffer-local, and
that the newly read item will be added to the history list. IMO this
wasn't clear enough so I ended up calling `add-to-history' myself, which
was redundant since `read_minibuf' does that already.