bug#16542: 24.3.50; When finding a file via a bookmark, that file is not part of file-name-history

[Bastien]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> 1. A user option such as what you describe, but with nil meaning
>>> "go for it generally: let the command decide", a non-nil list as
>>> you mention meaning "do not let these commands decide", and any
>>> other non-nil value meaning "do not let any command decide".
>> I think a cleaner solution would be to have two separate history lists:
>> 1. history of minibuffer input
>> 2. history of visited files
>> and a new option to select which history to access via M-p
>> in the minibuffer that reads a file name.
>
> Better would be to somehow give access to those two lists without going
> through an option.

The advantage of a simple option like

  (setq find-file-history '(bookmark dired))

is that users are likely to set it once and for all.

With two history variables and a way to access them separately or
together (e.g. depending on a toggle command in the minibuffer?), the
users may wonder which one they are currently accessing, overloading
their minds for this frequently used command...

Or at least, there should be an option to always search through the
extended history if that's the default behavior we want.

-- 
 Bastien