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

[Drew Adams <drew.adams@oracle.com>]

> I'm on Drew side here, I think a one-by-one approach is better,
> whether there is a general mechanism or not (yet).
> 
> Since there is no strong objection for fixing the bookmark-jump
> case, and since it's trivial to migrate this fix to a general
> solution when we'll have one, I'm willing to apply the fix if
> no-one objects in a week.

I did not object to the idea out of hand, and I agreed that
there are arguments in its favor (for `bookmark-jump').

However, to be clear: There is no hurry for this command to act
like that, and my preference would be to *not* make this change
now for that one command, and instead to wait until we address
the issue more generally.

E.g., a user option to give users some control over this.
The file-name history is, after all, _their_ history.

Starting down this road is not a great idea without a general
plan.  Until now, minibuffer histories are designed to reflect
only text _actually input from the minibuffer by the user_.

To change that design decision so that it becomes only a
guideline, which gets modulated by other influences (e.g., the
individual command; one or more user options overrule; etc.),
we should have a general plan for where we're headed - a new
design.

So I do not object strongly, but I think it is a bad idea
to set a precedent this way.  It is better to discuss the
general issue on emacs-devel.  And there certainly is no
hurry for this, when it comes to `bookmark-jump'.

If you really want to do this now for `bookmark-jump', then
a compromise could be to add a user option just for that,
i.e., in bookmark.el.  Then, if and when a more general
design is adopted, that option could be removed in favor of
a more general option.

That would let users retain the current `bookmark-jump'
behavior or not, as they prefer.