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

From: "Drew Adams" <[email-masked]>
Date: Sun, 13 Jan 2013 10:55:05 -0800

> > So it should be clear to anyone who actually reads what I 
> > wrote that I am _not against_ the idea of extending input
> > histories beyond minibuffer reading to other ways of
> > invoking the same behavior (in this case, accessing files).
> 
> You could have fooled me.

Apparently.  As I said, it should be clear to anyone who actually reads what I
wrote.

Can't say it any clearer: I am all in favor of letting users choose to
automatically add to an "input" history when they choose things (including file
names) in ways other than just by typing the name at a minibuffer prompt.

I am in favor of letting users _choose_ to do that, and choose specifically
whether to do it for different kinds of things (e.g., file names, as one kind)
and for different ways of choosing things (e.g., menu access, as one way).

> > But I also made it clear that it is important for users to 
> > be able to control whether and where and how much this is
> > done.  I argued against an automatic handling of all displayed
> > files by simply adding their names to `file-name-history'
> > willy nilly.
> 
> What is fundamentally different between typing a file name
> at "C-x C-f" prompt, and selecting a file name via the file
> selection dialog after clicking "File->Visit New File" on the
> menu bar?  Why would the former end up in the history, but
> not the latter?

Why indeed?  User preference - that's the difference that counts.

(For some definition of "fundamentally different" there are no fundamental
differences.  For any difference pointed to, you can reply that it is not
"fundamental".)

Certainly there is a difference between the two interactions you mention.  And
users can differ in whether they prefer that both interactions augment the
history.  Until now, Emacs Dev has preferred that only one of them do that.

Emacs Dev specifically _rejected_ the proposal to treat both menu access and
minibuffer-input access the same wrt input history.  Why?  Ask yourself what the
"fundamental difference" was behind that rejection.  Certainly some difference
was comprehended, and it must have seemed "fundamental" enough to Emacs Dev.

Well, that difference can obviously be important to some users - it has been
important enough that Emacs Dev decided, for _all_ users, against treating the
two the same.  Certainly Emacs Dev must have been right wrt at least some users.

> > Would you argue, for instance, that every face that has 
> > ever been shown in the current session must be automatically
> > added to `face-name-history'?
> 
> No one suggested such absurdity.

Precisely.

> I could turn the table and ask you whether it would make sense to let
> users customize insertion into history by file-name wildcards.  After
> all, some user, somewhere, may wish to insert *.cpp files, but not
> *.cxx, right?  That way lies madness.

No one suggested such absurdity.  But you are welcome to.

(In Icicles you can in fact retrieve a previously used completion pattern, but
it is on a different history list, as mentioned previously.)

> User options should serve specific workflows or use cases that make
> sense.  So far, I've given my use cases, but haven't heard any others
> that contradict my experience.  It would be nice to hear such
> real-life experiences, for a change.  That would make this discussion
> a whole lot more productive.

You've already heard from a couple people (not me) who mentioned that blanket
inclusion would pollute their histories with too much noise, and who cited a
previous thread for reference.  Their message was thanks, but no thanks.

The point is that users are different.

User A (a la Emacs Dev) does not want menu access, but only `M-x' access, to
contribute to the input history.  User B wants them both to contribute.  User C
wants also command-line args from Emacs startup and emacsclient file args to
contribute.  User D wants also file names used as shell-command args to
contribute, but only from shell use inside Emacs.  User E wants Emacs to try
also to get file-name args from shell commands used outside Emacs, and add those
too.

User F wants to include files opened from *grep*, but not from Dired.  User G
wants files opened from Dired, but only when opened singly (not all marked
etc.).  User H wants even the names of files copied using Dired (`C').  User I
wants those, as well as the names of Dired subdirs inserted (`i') and `C-x C-d'
targets, both dirs and file names matching wildcard patterns.  User J wants the
names of files acted on in Dired using `A', `Q', `B', `S', `P', and `Z'.  User
K...

I already agreed that each of the possibilities you listed in _your_ use case
can be useful: "They, and others, can all be useful."  Good suggestion of some
possibilities to consider.

Just let users decide which, if any, of them they want for their own use.
That's all.  Why should Emacs hard-wire Eli's choice of user interactions as the
only one to define when names are to be included?

It should be easy enough to come up with a list of possible file-choosing
interactions - like you did, and then present the user with an option that
allows a choice of which interactions should augment `file-name-history'.
(Similarly, for other histories, and perhaps another, short list covering all
histories.)

The list for file-name preferences could be fixed by Emacs Dev.  (Or it could
perhaps even be extendable, if we devise a means to map interaction names to
controlling code.  To be clear, I have no such code in my pocket now.)

If you like, Eli's Preferred Interactions could even serve for the default value
of the option controlling file-name inclusion:

* minibuffer input
* menu access
* emacsclient file-name arg
* RET in Dired (mouse too?  `e', `f', `o', `C-o', `a', `F' too?)
* files previously visited in the same session but since killed

Did I get your preferred list right?  Sounds like a good start, to me.  Turn
those all on for the default behavior, if you like.

But should Dired perhaps have its own option governing file interactions (see
above for possibilities)?  That might make sense too.  Likewise, some other
modes (e.g. grep/compilation mode).

My point is only to give individual users the choice.