bug#12915: 24.2.50; Visiting a file via drag-and-drop should add it to the history ofvisited files

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

> >> The history of visited files should contain every visited
> >> file, regardless of the way it was visited (command line
> >> argument, drag-n-drop, menu item, C-x C-f...)
> >
> > ... and when the file is visited via bookmarks (e.g.
> > `C-x r b foo <RET>').  (I've just missed this feature).
> 
> This feature is relatively easy to implement.
> 
> I think it is best done by adding an optional argument 
> `add-history' to `find-file' (and similar functions like
> `find-file-other-frame'), so that Lisp callers can specify to
> update `file-name-history' even if the file name was not read
> interactively.  Any objections?

Yes, FWIW, I completely disagree with this - the aim.

History variables are about _user input_.  For file names, that means
interactive use of a file-finding command.  They are not just about accessing a
file, or using a command, or mentioning a variable, or ....  They are INPUT
histories.

In the past there have been suggestions to add commands associated with menu
items that a user accesses interactively to `extended-command-history'.  That
suggestion was rejected (why?), even with the proviso that it be governed by a
user option.

This proposed change goes against the intention/meaning of Emacs input
histories.

The proper solution is for commands that read file names to DTRT wrt
`file-name-history' - TRT for that command.

If for instance, a bookmark jump command visits a file (it need not) then it
could, itself, explicitly add that file's name to `file-name-history'.  The
command knows what TRT is.  And the user knows more than does the command, and
should ultimately decide.

Normally, changing `file-name-history' would not (_should_ not) be done by a
bookmark jump command, unless the file name was provided as user input.  That's
what these histories are for: _user input_.  Past input provides candidates for
future input.

A bookmarking command that reads a bookmark name puts that bookmark name on
`bookmark-history'.  A priori, it should not also put the visited file name on
`file-name-history'.  Not without some user agreement (e.g. via an option
specific for this wrt bookmarks).

This proposed change is misguided, IMHO.  I'm surprised that both Emacs
maintainers apparently immediately signed on to it.

It is so easy for any command (or any function - but this should be done in the
context of a command and its user interaction) to add a name to any history,
according to what it deems is TRT.

There is no need to do this in some low-level, automatic way.  No need - and
it's generally the wrong thing to do.

Is it hard to solve the specific problem raised by the enhancement request (it
is not a bug report): have drag-and-drop add the name of the file to
`file-history', without going in the direction you are suggesting?  Why is that
difficult to address specifically?

And since users should be able to control this, how would they do it?  The
enhancement request also mentions menu-item access and bookmark access.
Different users will feel differently about whether those should all be lumped
together in this respect.

I mentioned the case of menus and commands because it is similar: accessing a
command via a menu is a different user action than typing its name into the
minibuffer for `M-x'.  A priori, it is only actual, historical command-name
input that we want to later provide for command-name reading.

But a user might later want to repeat that menu-accessed command by name, using
the minibuffer.  That's why this feature was proposed.  (This has been an
Icicles user option for years.  Some people use it, some do not.  It is turned
on by default.)

But it's also why this kind of thing should be controlled by specific user
options (one for menu items, one for file bookmarks, etc.).

A user should opt into having other commands, which do not _read_ a name (e.g.
file), also add a name to the history.

This is no less important for file dragging-&-dropping, or file access by menu,
than it is for accessing commands by menu.

The important point is that we should not generalize the addition of names (of
files or whatever) to histories beyond _user interaction_ or in some automatic
way beyond user control.

And for any user interaction besides _reading_ the name, users should be able to
control (e.g. via an option) whether the name gets added to the input name
history.

For commands like bookmark jumping, a user should be able to decide whether
`file-name-history' should be augmented, in addition to `bookmark-history'.

I hope you will think a little more about this.