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

[Drew Adams]

> > `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.
> 
> A new variable (e.g. `file-name-history-variable') could be introduced
> to hold the name of the history variable.  The default would be the
> currently existing `file-name-history'.  And the other possible value
> would be a new history variable (e.g. `file-name-extended-history')
> that will collect all visited/displayed file names like:
> 
> (defvar file-name-history nil
>   "History list of file names entered in the minibuffer.")
> 
> (defvar file-name-extended-history nil
>   "History list of files visited/displayed in the current session.")
> 
> (defcustom file-name-history-variable 'file-name-history
>   "History list to use in the minibuffer that reads a file name.
> The value of this variable should be a symbol; that symbol
> is used as a variable to hold a history list for the file names."
>   :group 'files
>   :type 'symbol)
> 
> Then the users would be able to customize it to 
> `file-name-extended-history':
> 
> (custom-set-variables
>  '(file-name-history-variable file-name-extended-history))

Having separate variables does not deal with the heart of the problem being
discussed.

`read-file-name' already adds correctly to the history.  The problem is that
some commands that let users choose files without entering a name - i.e., which
do _not_ use `read-file-name', should also (optionally) augment the history.

A mouse-click or menu command that just wraps a command that if called
interactively would use `read-file-name' should itself (optionally) augment the
history.