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

> > Perhaps I wasn't clear enough, but what I had in mind was adding to
> > the history every file visited _under direct user request_ (with
> > either `C-x C-f', drag-n-drop, click on dired buffer, jump to
> > bookmark, menu item, command line argument, etc).
> 
> My observations were the result of the experiment when I optimistically
> tried this feature, but quickly became annoyed by too many unnecessary
> elements added by direct user request in dired, next-error, etc
> to the minibuffer history.  When I browse a lot of files using dired
> then I likely re-visit them again with the same dired commands,
> not with C-x C-f.  OTOH, I expect to see only files visited 
> with C-x C-f in the history of C-x C-f.
> 
> What do you think about adding these file names not to the history
> but to the suggestions like in web browsers where the top elements of
> the suggestions drop-down list are the most frequently visited pages
> (in Emacs this would mean the most frequently visited files).

No, I think they belong in the history - they name files that were in fact
chosen by the user in the past.  That's history.

But you and other users should be able to choose not to include such names,
which were never entered as minibuffer input.

Your experiment and your conclusion should serve as a valuable lesson: one
person's convenience is another's inconvenience.

So history, yes, but optionally, please.

---

I will add, with Dired as an example, that the use of file _display_ as the sole
criterion for history inclusion is flawed in the opposite direction: including
too few, not too many, file names.  It is misguided (off target).

As an example, the use of non-display/visit commands in Dired, which act on a
file but do not display it, should constitute another potential source of file
names to add to the history.

`file-name-history' was designed to be augmented by `read-file-name', whenever a
file name is input.  That includes commands that do not display/visit the file.
This way of interactively choosing files should not be ignored, just because
someone finds an easy way to hook history augmentation into file-buffer display.

That a command such as `dired-do-compress' (`Z'), `dired-do-copy' (`C'), or
`dired-do-byte-compile' (`B') does not augment `file-name-history', simply
because it involves a different user interaction from reading the file name, is
a bit silly.  The user chooses a file interactively; s?he just does not need to
type the file name.

Such a command is in effect a wrapper around a command that uses
`read-file-name'.  It provides for different user interaction - nothing more.
The same is true for a mouse command such as
`dired-mouse-find-file-other-window' (`mouse-2'): it's just a wrapper around
`find-file-other-window', in order to provide a different user interaction.

A user should at least have the possibility to include names of files acted on
in these ways.  _Display_ of a chosen file is not an adequate criterion.  It's
about the user choosing a file name, nothing more.

(Whether that should happen for all marked files in Dired or only when a key
such as `C' is used with no files marked is a different question.)

The same thing holds for commands that use `completing-read' instead of
`read-file-name'.  Commands that are wrappers of, or otherwise substitutes for,
such input-reading commands, do not augment the history today.  They should
(optionally).

Using a menu or a mouse click to invoke an action that can also be invoked by a
command that reads input in the minibuffer should (optionally) add the target
name to the history.