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

[Drew Adams]

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

I see nothing "cleaner" about that.  But it is a reasonable proposal.

Here are some arguments against it:

a. That makes the lists exclusive - the file names are not merged
into one list.  So they are not accessible by simple cycling.

Unless you meant that #2 would subsume #1 as a proper subset.
(But a file name can be entered without the file being visited,
so your description of #2 would need to be changed slightly, if
we assume that #2 includes everything in #1.)

b. It means that the choice of which of those exclusive histories
to use would be decided ahead of time, when the user option is set.

c. It would not give the command any control over what is
appropriate for it.  I prefer that (i) the user have ultimate
control, and (ii) when allowed by the user, the command can decide.

> Actually we already have a history of recently visited files
> in recentf, so we could add `bookmark-jump' to `recentf-used-hooks'.
> Or maybe this is not needed because it already contains `find-file-
> hook'.

I agree that recentf should include files visited by jumping to
bookmarks.  I think that is already the case, but if not, yes,
let's fix that first, for sure.

The purpose of recentf is to record recently visited files.  The
purpose of `file-name-history' is to record file names entered in
the minibuffer.  Different purposes, for different uses.

Yet another approach would be to let users cycle through recentf
files during file-name input, using a different key from `M-p'
etc.  But that has the same drawback as your proposal: separate
list do not reflect a single chronological history.

Bastien's original suggestion, and the user option I presented,
include (some) visited files in `file-name-history', not just
in the recentf history.  I think this is clean and simple, and
the option I suggested (or similar) gives users and commands
adequate control over the behavior.

(But as we generalize from bookmarks, this discussion really
belongs in emacs-devel, not just this bug thread.)