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

[Drew Adams]

> > It's a file-name _input_ history - generalized at most to
> > a user-request-for-the-file history.  It is not just a 
> > file-display history.
> 
> You keep saying that, time and again,

You're very inventive.

Name one other time when I said that.
Name two, since you claim "time and again".

> but I have yet to see an explanation and specific reasons
> why this history should only keep file names typed in the
> mini-buffer,

See (emacs) Minibuffer History.
See (elisp) Minibuffer History.

Really, please do take a look at that doc.  It describes what minibuffer
histories are and what they are for.  That is, it describes the design/intention
- so far.

I am not inventing anything here - except that I too am in favor of generalizing
the input history to "a user-request-for-the-file history", allowing for
different forms of such request.

Turn it around - where do you see that the Emacs doc says that
`file-name-history' is for every file that has ever been displayed?  Similarly,
any other minibuffer history variable.

A minibuffer input history is, well, a minibuffer input history.  It is a
history of your past inputs for a particular command or a particular kind of
command (e.g. commands that read file names).  That is the design, not just some
past implementation limitation.

And I was quite clear that it _can_ be useful to extend this to names introduced
indirectly by other means - other user interactions, besides simply typing a
name in the minibuffer.

To back that up, I gave a specific example of my having proposed this, long ago,
for commands that a user invokes indirectly (not by name) by using a menu.  And
that discussion (where the proposal was rejected) dealt also with implementation
specifics - it was not just pie in the sky.  And I mentioned that I implemented
that years ago for Icicles.

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).

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.

> nor why might the user object to having file names added to that
> history when files are visited via menus or DND or whatever.

Users are different.  And they might want different behavior for different kinds
of names or for different commands.

A user does not necessarily want this or that input history polluted by names
that s?he never entered as input.  A given user might well want input history to
include only actual inputs (as now), to keep cycling or searching more succinct
or for other reasons.

Same reason a user might not want to include the names of commands s?he invokes
using a menu.  Ask yourself why Emacs Dev rejected that possibility when I
proposed it, if you want reasons why a user might consider such inclusion to
pollute the actual input history with noise.

But a different user might not object at all, and might appreciate this feature.
That's why (a) I am not opposed to making such possibilities available to users
and (b) I stated that users should be able to control this.  BOTH: (a) new
possibilities and (b) ability to choose among them.

There are many ways to access a file, or invoke a command, or get information
about a variable.  We should not assume that all users want all such ways to be
amalgamated when it comes to augmenting specific "input histories".

I hope it is clear to you now that I am not against giving users the opportunity
to retrieve names implicated by past interactions besides just minibuffer input.
Far from it.

As another example of that, in Icicles you can retrieve past text that you have
typed in the minibuffer during completion but which you never entered using RET.
You do not use the minibuffer history to do that, however - the two histories
are kept separate and accessed differently.

Having that completion-content history is useful because Icicles lets you do
multiple things with different, or even with multiple, completion candidates,
based on the current minibuffer text.  You might open several files during a
file-finding command without ever hitting RET (e.g., hitting C-g to end
instead).

The point is that yes, it can be useful for users to have additional sets of
names that were used in some way in the past (even indirectly/implicitly),
making them available for later reuse.  I do not disagree with that at all - I
have even proposed it.

> Without specific and detailed explanations, this is just "he said, she
> said" kind of argument, which can never lead to any constructive
> discussion.

Blah.  More of your inventive "You keep saying that, time and again,..."

No one said anything like "he said" or "she said" - at all.  Except you.  And no
one said what you claim I said.

And I agree with you that that kind of thing is not constructive.  So skip it,
please.

> My use case that might benefit from this is when a file is visited
> because some program invoked emacsclient.  I find myself in the need
> of revisiting the file after I did "C-x #", and then I'm annoyed that
> I cannot find it in the history, until it hits me that "oh, yes, it
> was visited via emacsclient..."
> 
> Another similar situation is when a file was visited via RET in the
> Dired buffer, then the buffer was killed, and then one wants to
> revisit the file with "C-x C-f".
> 
> I believe this can be generalized: a file that was visited without
> typing its name in the minibuffer, then the buffer was killed, and
> then the user wants to revisit the file.

And I would not be against any such possibilities.  I tried to make that clear.
They, and others, can all be useful.

User A (you perhaps) might want the name of every file that is ever displayed in
any way to be added to the input history.  User B might want actually-input file
names plus names of files accessed using Dired to be included.  User C might
want names input to `find-file' etc. and names input to emacsclient to be
included.  User D might want those plus all file names used in shell commands,
even outside Emacs (parsing shell command histories or whatever).  User E might
want to include all file names present as text in any buffer.

The discussion here can focus on file names - that's fine, and an important
case.  But similar considerations apply generally to any kind of name that can
be used in an input history.

And especially when it comes to proposals to treat things in an automatic,
blanket way, it can help to think about doing the same for other kinds of names.
That might help discover whether the proposed handling might not be such a great
idea after all.

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'?  Some users
might like that; some might not - for some it might be helpful; for others it
might represent just noise, getting in the way of reusing a real past face
choice.

There are lots of possibilities.  My argument is against an automatic
one-size-fits-all approach that takes control away from users and radically
changes the meaning and behavior of traditional Emacs minibuffer histories.

I am not against extending, under user control, specific input histories in
various ways.

I would argue though that such ways should involve user interaction - actually
_choosing_ the thingie that is named in some way, as opposed to simply all
adding the names of all files or all faces that have so far been
displayed/accessed/used etc.

The same is true for dealing with other sets of names - completion candidates,
for instance.  Some libraries let users of `C-x b' access also recently accessed
files (per recentf), or names cached using filecache, during buffer-name
completion.  Icicles does that, and IIRC, Ido and Helm offer that also.

But some users will want those names included with buffer-name candidates, and
some users will not.  And some who want them included will want fewer or more
such names (different limits).  In Icicles there are user options to control
such behavior (one for recentf names, one for filecache names).

That is the kind of argument I am making here: give users the _possibility_ of
including, as part of `file-name-history', file names not actually typed in the
minibuffer.  But give them also the ability to _choose_ which such names get
added, as defined by how the files were chosen for access.  Different strokes
for different folks.

This is a normal thing to consider whenever you are thinking about including
additional candidates: whether, what kind, how many.  That's all.  And let
individual users decide.