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

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

[Dani Moncayo]

Please, when a file is visited via drag-and-drop, add that file to the
history of visited files (so that I can revisit it with `C-x C-f M-p',
for example).  I don't see the point of not doing that.

TIA.


In GNU Emacs 24.2.50.1 (i386-mingw-nt6.1.7601)
 of 2012-11-16 on MS-W7-DANI
Bzr revision: 110888 rgm@gnu.org-20121116184100-sv2ns2ogdd711a7v
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --with-gcc (4.7) --no-opt --enable-checking --cflags
 -Ic:/emacs/libs/libXpm-3.5.10/include -Ic:/emacs/libs/libXpm-3.5.10/src
 -Ic:/emacs/libs/libpng-1.2.37-lib/include -Ic:/emacs/libs/zlib-1.2.5
 -Ic:/emacs/libs/giflib-4.1.4-1-lib/include
 -Ic:/emacs/libs/jpeg-6b-4-lib/include
 -Ic:/emacs/libs/tiff-3.8.2-1-lib/include
 -Ic:/emacs/libs/libxml2-2.7.8-w32-bin/include/libxml2
 -Ic:/emacs/libs/gnutls-3.0.9-w32-bin/include
 -Ic:/emacs/libs/libiconv-1.9.2-1-lib/include'

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1252
  default enable-multibyte-characters: t


-- 
Dani Moncayo

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

[Glenn Morris]

Dani Moncayo wrote:

> Please, when a file is visited via drag-and-drop, add that file to the
> history of visited files (so that I can revisit it with `C-x C-f M-p',
> for example).  I don't see the point of not doing that.

On a related note, I've always found it irritating that the same is true
of files specified on the command line:

emacs -Q README &
C-x C-k README RET
C-x C-f M-p
  -> "Beginning of history; no preceding item"

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

[Dani Moncayo]

>> Please, when a file is visited via drag-and-drop, add that file to the
>> history of visited files (so that I can revisit it with `C-x C-f M-p',
>> for example).  I don't see the point of not doing that.
>
> On a related note, I've always found it irritating that the same is true
> of files specified on the command line:
>
> emacs -Q README &
> C-x C-k README RET
> C-x C-f M-p
>   -> "Beginning of history; no preceding item"

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

-- 
Dani Moncayo

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

[Dani Moncayo]

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

-- 
Dani Moncayo

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

[Chong Yidong]

Dani Moncayo <dmoncayo@gmail.com> writes:

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

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

[Stefan Monnier]

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

Maybe a more automatic way is to provide a `display-buffer-hook', that's
run from `set-window-buffer', and then have find-file-noselect use this
hook to add the file name onto the history if the buffer is shown to
the user.


        Stefan

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

[martin rudalics]

 > Maybe a more automatic way is to provide a `display-buffer-hook', that's
 > run from `set-window-buffer', and then have find-file-noselect use this
 > hook to add the file name onto the history if the buffer is shown to
 > the user.

`buffer-list-update-hook' ?

martin

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

[Stefan Monnier]

>> Maybe a more automatic way is to provide a `display-buffer-hook', that's
>> run from `set-window-buffer', and then have find-file-noselect use this
>> hook to add the file name onto the history if the buffer is shown to
>> the user.
> `buffer-list-update-hook' ?

Is it run when we set-display-buffer?


        Stefan

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

[martin rudalics]

 >> `buffer-list-update-hook' ?
 >
 > Is it run when we set-display-buffer?

If you mean `set-window-buffer', it will so soon.  But since it's also
run elsewhere (e.g. by `kill-buffer') the function you put on the hook
probably needs a non-nil return value from `get-window-buffer'.

martin

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

[Drew Adams]

>  > Maybe a more automatic way is to provide a 
>  > `display-buffer-hook'...
> 
> `buffer-list-update-hook' ?

File-name input is not about a change in the list of buffers or the displayed
files.  It is about files that the user has interactively requested to access.
In particular, requested by entering the file name.

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

[Drew Adams]

> Maybe a more automatic way

More automatic is even worse.  _User interaction_ (mainly, typing a name) should
control whether an _input history_ gets augmented.

That should not happen automatically each time a file is displayed (or a
variable's doc is shown, or a function is called that might happen to be a
command, or...)

> is to provide a `display-buffer-hook', that's
> run from `set-window-buffer', and then have 
> find-file-noselect use this hook to add the file
> name onto the history if the buffer is shown to
> the user.

It's not clear whether you are actually suggesting that the file name should be
added unconditionally whenever the file is displayed.

If you are, that's the worst possible thing, IMO.  Just because a file is
displayed does not mean that a user wants that name to be added to the input
history for file names.

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.

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Sat, 12 Jan 2013 10:01:23 -0800
> Cc: 12915@debbugs.gnu.org
> 
> If you are, that's the worst possible thing, IMO.  Just because a file is
> displayed does not mean that a user wants that name to be added to the input
> history for file names.
> 
> 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, but I have yet to see an
explanation and specific reasons why this history should only keep
file names typed in the mini-buffer, nor why might the user object to
having file names added to that history when files are visited via
menus or DND or whatever.

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

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.

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.

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <monnier@iro.umontreal.ca>, <cyd@gnu.org>, <12915@debbugs.gnu.org>
> Date: Sat, 12 Jan 2013 14:43:28 -0800
> 
> > > 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.

Not at all.

Drew in http://lists.gnu.org/archive/html/bug-gnu-emacs/2013-01/msg00408.html:

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

Drew in http://lists.gnu.org/archive/html/bug-gnu-emacs/2013-01/msg00409.html:

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

Drew in http://lists.gnu.org/archive/html/bug-gnu-emacs/2013-01/msg00412.html:

> File-name input is not about a change in the list of buffers or the displayed
> files.  It is about files that the user has interactively requested to access.
> In particular, requested by entering the file name.

As you see, I didn't invent anything.

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

I named 3 above.  I meant in this thread.

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

The docs are not a catechism.  We wrote it, and we can change it if we
decide to do so.

I asked for _your_ take of this, I'd like to see your use cases when
adding to file-name history names of files that were not typed in the
minibuffer would be the wrong thing.

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

Emacs docs are not requirements.  They are descriptions of a certain
state of the package behavior.  When the behavior changes, we update
the docs.  We never treat the docs as requirements that we need to
fulfill.

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

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

> A user does not necessarily want this or that input history polluted by names
> that s?he never entered as input.

We _are_ talking about selecting files by their names.  The name
doesn't have to be typed in its entirety.  E.g., typing "foo TAB" into
the minibuffer, then clicking on "foobar" in *Completions* does end up
in the history, although the user only typed "foo".

Where do you draw the line?  How do you explain the difference to
users, without going into the internals, which users don't care about?

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

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.

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

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.

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

[Drew Adams]

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

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

[Drew Adams]

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

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

[Juri Linkov]

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

When this feature was discussed last time at
http://thread.gmane.org/gmane.emacs.pretest.bugs/9253/focus=43774
I found it too irritating that it clutters the minibuffer history
with too many unnecessary elements that were not entered manually.

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

Since this is a matter of personal preference, I think not Lisp callers
but Emacs users should be able to specify what to add to the history.

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

[Dani Moncayo]

> When this feature was discussed last time at
> http://thread.gmane.org/gmane.emacs.pretest.bugs/9253/focus=43774
> I found it too irritating that it clutters the minibuffer history
> with too many unnecessary elements that were not entered manually.
>
>> 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?
>
> Since this is a matter of personal preference, I think not Lisp callers
> but Emacs users should be able to specify what to add to the history.

FWIW, I also don't want to pollute the minibuffer history, obviously.
That would make harder to find the entries you care about.

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

-- 
Dani Moncayo

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

[Stefan Monnier]

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

Do you agree that "file displayed" is a good enough approximation?
What are the cases where Emacs displays a file without it being "under
direct user request"?


        Stefan

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

[Drew Adams]

> > 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).
> 
> Do you agree that "file displayed" is a good enough approximation?
> What are the cases where Emacs displays a file without it being "under
> direct user request"?

Certainly not.  You are playing with words here: choosing to display the file
is, yes, under direct user request.  That does not mean that choosing to add its
name to the history is under direct user request.

A user requesting that a given file be displayed is one thing.  A user wanting
the name of a file that s?he displays using a particular method (e.g.
command-line arg) to be added to the history is another thing.

Users should be able to specify the name-adding behavior they want.  Simply
adding the name of every file that gets displayed, no matter how, does not give
users the control they deserve.

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

[Dani Moncayo]

> Users should be able to specify the name-adding behavior they want.  Simply
> adding the name of every file that gets displayed, no matter how, does not give
> users the control they deserve.

FWIW, I'd not need such degree of control.  Simply adding to the
history every file I've explicitly visited would be TRT.

I'm not sure whether there is a real demand for such degree of
control, but if there is, go ahead...

-- 
Dani Moncayo

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

[Stefan Monnier]

>> What are the cases where Emacs displays a file without it being "under
>> direct user request"?
> You are playing with words here:

No, you're simply misreading me.


        Stefan

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

[Dani Moncayo]

>> 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).
>
> Do you agree that "file displayed" is a good enough approximation?
> What are the cases where Emacs displays a file without it being "under
> direct user request"?

I'm not quite sure, but I think that your approximation could fail in
cases where some lisp program visits and displays files as part of its
functioning, but I don't have a concrete use case right now.

-- 
Dani Moncayo

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

[Stefan Monnier]

> I'm not quite sure, but I think that your approximation could fail in
> cases where some lisp program visits and displays files as part of its
> functioning, but I don't have a concrete use case right now.

Any programmatic solution will have false negatives and/or false
positives, so "no concrete use case" sounds like an endorsement to me.


        Stefan

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

[Drew Adams]

> FWIW, I also don't want to pollute the minibuffer history, obviously.
> That would make harder to find the entries you care about.

Yes, and different users can prefer different things.  One person's pollution or
noise is another person's convenience feature or dwim.

And the same user can want different things at different times or in different
contexts.

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

Yes, but users should also be able to pick and choose which kinds of
file-choosing interactions should result in adding names to `file-name-history'.
Different users...different contexts...

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

[Juri Linkov]

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

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

[Dani Moncayo]

On Mon, Jan 14, 2013 at 8:52 AM, Juri Linkov <juri@jurta.org> wrote:

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

For my use cases, I'd prefer the files get added to the history.  It
would be more intuitive for me, because I think of that list as the
list of files I've visited so far.

I understand your point too, therefore I think that maybe Drew was
right: not all of us (users) want the same behavior here, thus such
behavior should be customizable.

-- 
Dani Moncayo

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

[Stefan Monnier]

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

Thanks, yes, that makes a lot of sense (tho obviously it depends on
your use pattern).


        Stefan

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

[Drew Adams]

> > 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.
> 
> Thanks, yes, that makes a lot of sense

Just as it makes a lot of sense to other users to include those files in the
history, so they _can_ access them using `C-x C-f' with `M-p', `M-s' etc.

> (tho obviously it depends on your use pattern).

That is precisely the point.

So make it possible, but not mandatory, for a user to have such Dired commands
augment `file-name-history'.  Let individual users choose the behavior they
want.

And this applies just as much to commands (e.g. `C') that act on a file but do
not display it.

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

[Drew Adams]

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

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

[Juri Linkov]

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

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.

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

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Date: Sun, 13 Jan 2013 11:56:20 +0200
> Cc: 12915@debbugs.gnu.org
> 
> When this feature was discussed last time at
> http://thread.gmane.org/gmane.emacs.pretest.bugs/9253/focus=43774
> I found it too irritating that it clutters the minibuffer history
> with too many unnecessary elements that were not entered manually.

That discussion also suggested a very simple device to avoid such
cluttering, and only add to history files which Emacs visited by user
commands.  So this difficulty doesn't seem to be a real one.

> Since this is a matter of personal preference, I think not Lisp callers
> but Emacs users should be able to specify what to add to the history.

Emacs already has way too many options.

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

[Drew Adams]

> > When this feature was discussed last time at
> > http://thread.gmane.org/gmane.emacs.pretest.bugs/9253/focus=43774
> > I found it too irritating that it clutters the minibuffer history
> > with too many unnecessary elements that were not entered manually.
> 
> That discussion also suggested a very simple device to avoid such
> cluttering, and only add to history files which Emacs visited by user
> commands.

Users should be able to choose for themselves which kinds of interaction
(drag-n-drop, menu access, etc.) should result in adding the file name.  One
size does not fit all.

> So this difficulty doesn't seem to be a real one.

Not for you, perhaps.
 
> > Since this is a matter of personal preference, I think not 
> > Lisp callers but Emacs users should be able to specify what
> > to add to the history.
> 
> Emacs already has way too many options.

Wrong.  That's akin to saying that Emacs users have too many options, too much
freedom to customize Emacs.

bug#3909: 23.1.50; Drag drop events in command history?

[Lars Ingebrigtsen]

Dani Moncayo <dmoncayo@gmail.com> writes:

>>> Please, when a file is visited via drag-and-drop, add that file to the
>>> history of visited files (so that I can revisit it with `C-x C-f M-p',
>>> for example).  I don't see the point of not doing that.
>>
>> On a related note, I've always found it irritating that the same is true
>> of files specified on the command line:
>>
>> emacs -Q README &
>> C-x C-k README RET
>> C-x C-f M-p
>>   -> "Beginning of history; no preceding item"
>
> Indeed.  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...)

The discussion here veered off into generalities, and nothing was done.

The two practical suggestions were:

1) To add an optional parameter to `find-file' to make it push the
filename onto `file-name-history'.  Then we could adjust callers
according to taste: I think drag and drop and command line arguments
should land on the history.

2) To add a `display-buffer-hook' to do the same if the file actually
ends up being displayed, so this pushing would happen deep in
`find-file-noselect'.

I think 1) is attractive in that it's very straightforward and simple to
understand.  2) is attractive in that we don't put file names into the
history unless we actually read the file, and we don't have to adjust
function parameters for the other `find-file-*' commands, too.

I think I prefer 1), because it's easier to reason about.

Anybody got an opinion?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#12915: [External] : bug#12915: bug#3909: 23.1.50; Drag drop events in command history?

[Drew Adams]

> The two practical suggestions were:
> 
> 1) To add an optional parameter to `find-file' to make it push the
> filename onto `file-name-history'.  Then we could adjust callers
> according to taste: I think drag and drop and command line arguments
> should land on the history.
> 
> 2) To add a `display-buffer-hook' to do the same if the file actually
> ends up being displayed, so this pushing would happen deep in
> `find-file-noselect'.
> 
> I think 1) is attractive in that it's very straightforward and simple to
> understand.  2) is attractive in that we don't put file names into the
> history unless we actually read the file, and we don't have to adjust
> function parameters for the other `find-file-*' commands, too.
> 
> I think I prefer 1), because it's easier to reason about.
> 
> Anybody got an opinion?

In the #12915 thread both Juri and I argued for having
(multiple) means of _user_ control.  And several such means
were suggested.

I said, for example:

  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.

Juri said, specifically to argue against your #1::

  Since this is a matter of personal preference, I think
  not Lisp callers but Emacs users should be able to specify
  what to add to the history.

There are lots of good suggestions in the thread - many
specific and some based on actual implementation and use.
Asking "Anybody got an opinion?" is an invitation to
ignore lots of opinions already carefully expressed. 

bug#3909: bug#12915: bug#3909: 23.1.50; Drag drop events in command history?

[Juri Linkov]

> 1) To add an optional parameter to `find-file' to make it push the
> filename onto `file-name-history'.  Then we could adjust callers
> according to taste: I think drag and drop and command line arguments
> should land on the history.

I don't think anyone would object to such patch:

diff --git a/lisp/startup.el b/lisp/startup.el
index 456c01efd1..46252e7b93 100644
--- a/lisp/startup.el
+++ b/lisp/startup.el
@@ -2391,6 +2391,7 @@ command-line-1
 				  (command-line-normalize-file-name name)
 				  dir))
 			   (buf (find-file-noselect file)))
+		      (add-to-history 'file-name-history (abbreviate-file-name file))
 		      (setq displayable-buffers (cons buf displayable-buffers))
                       ;; Set the file buffer to the current buffer so
                       ;; that it will be used with "--eval" and

And the same for drag and drop.

bug#3909: bug#12915: bug#3909: 23.1.50; Drag drop events in command history?

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

>> 1) To add an optional parameter to `find-file' to make it push the
>> filename onto `file-name-history'.  Then we could adjust callers
>> according to taste: I think drag and drop and command line arguments
>> should land on the history.
>
> I don't think anyone would object to such patch:

[...]

> @@ -2391,6 +2391,7 @@ command-line-1
>  				  (command-line-normalize-file-name name)
>  				  dir))
>  			   (buf (find-file-noselect file)))
> +		      (add-to-history 'file-name-history (abbreviate-file-name file))

I thought it might be nice to have these "extra" additions to
`file-name-history' in one central place (in case we decide to make it
optional).

But I guess we could just have a function like
`add-to-file-name-history' if we wanted to future-proof that?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#12915: bug#3909: 23.1.50; Drag drop events in command history?

[Juri Linkov]

>>> 1) To add an optional parameter to `find-file' to make it push the
>>> filename onto `file-name-history'.  Then we could adjust callers
>>> according to taste: I think drag and drop and command line arguments
>>> should land on the history.
>>
>> @@ -2391,6 +2391,7 @@ command-line-1
>>  				  (command-line-normalize-file-name name)
>>  				  dir))
>>  			   (buf (find-file-noselect file)))
>> +		      (add-to-history 'file-name-history (abbreviate-file-name file))
>
> I thought it might be nice to have these "extra" additions to
> `file-name-history' in one central place (in case we decide to make it
> optional).

`find-file' can't be such central place, because there are many other
file-reading commands like find-file-other-window, find-file-other-frame, …

Long ago I tried:

  (defun add-file-name-to-history ()
    "Add the name of the file just opened to the history."
    (when (and buffer-file-name (not buffer-read-only))
      (add-to-history 'file-name-history buffer-file-name)))
  (add-hook 'find-file-hook 'add-file-name-to-history)
  (add-hook 'first-change-hook 'add-file-name-to-history)

But it clutters up the history.  Maybe a new defcustom e.g.
`add-file-name-commands' could help with such options
as a list of command names to selectively add their args to the history,
or a regexp of command names.

> But I guess we could just have a function like
> `add-to-file-name-history' if we wanted to future-proof that?

This is not specific to the file history, the same requests were about
e.g. describe-function, describe-variable, …  So also tried:

  (define-advice describe-function (:before (function))
    "Add function name to the history."
    (when (and function (symbolp function))
      (add-to-history 'minibuffer-history (symbol-name function))))

  (define-advice describe-variable (:before (variable &optional _buffer _frame))
    "Add variable name to the history."
    (when (and variable (symbolp variable))
      (add-to-history 'minibuffer-history (symbol-name variable))))

  (define-advice describe-symbol (:before (symbol &optional _buffer _frame))
    "Add symbol name to the history."
    (when (and symbol (symbolp symbol))
      (add-to-history 'minibuffer-history (symbol-name symbol))))

But still too much clutter.  Maybe a more general defcustom is needed
that will accept a list of 3 parameters: command name, its argument number,
and a history variable, e.g. '((find-file-other-window 1 file-name-history) …)

bug#3909: bug#12915: bug#3909: 23.1.50; Drag drop events in command history?

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

>> But I guess we could just have a function like
>> `add-to-file-name-history' if we wanted to future-proof that?
>
> This is not specific to the file history, the same requests were about
> e.g. describe-function, describe-variable, …  So also tried:

I think you're over-thinking this.  :-)  There's a lot of controversial
things we could be doing in the history area, but we're not doing it,
because:

> But still too much clutter.

Adding drag'n'drop file names and command name file names isn't
controversial, and can be done easily, so we should just do that.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#3909: bug#12915: bug#3909: 23.1.50; Drag drop events in command history?

[Juri Linkov]

> Juri Linkov <juri@linkov.net> writes:
>
>>> But I guess we could just have a function like
>>> `add-to-file-name-history' if we wanted to future-proof that?
>>
>> This is not specific to the file history, the same requests were about
>> e.g. describe-function, describe-variable, …  So also tried:
>
> I think you're over-thinking this.  :-)

I completely agree.

> There's a lot of controversial things we could be doing in the history
> area, but we're not doing it, because:
>
>> But still too much clutter.
>
> Adding drag'n'drop file names and command name file names isn't
> controversial, and can be done easily, so we should just do that.

Then it should be enough just to add after the find-file call:

  (add-to-history 'file-name-history (abbreviate-file-name file))

in command-line-1 and drag-n-drop functions.

bug#3909: bug#12915: bug#3909: 23.1.50; Drag drop events in command history?

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> Then it should be enough just to add after the find-file call:
>
>   (add-to-history 'file-name-history (abbreviate-file-name file))
>
> in command-line-1 and drag-n-drop functions.

I've now done so, but via a trivial helper function, and I'm closing
this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no