[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#16542: 24.3.50; When finding a file via a bookmark, that file is not

From: Drew Adams
Subject: bug#16542: 24.3.50; When finding a file via a bookmark, that file is not part of file-name-history
Date: Sat, 25 Jan 2014 00:42:29 -0800 (PST)

> FWIW: There are other cases (besides "via the bookmarks buffer") where
> a file is visited but not added to the file-name-history.
> Bug #12915 contains a general discussion about the matter.

Yes, thank you, Dani.

FWIW, I will repeat just this part from my post in that thread:

   The proper solution is for commands that read file names to DTRT
   wrt `file-name-history' - TRT for that command.

IOW, it is up to the command.  It should not be the case that the
mere fact of putting file contents into a buffer (e.g. via
`find-file-noselect'), or even the mere fact of "visiting" a file,
should place that file name into `file-name-history'.

Any given command can decide (i.e., be designed) to update the history
that way, but this should not be something general, i.e., done in
a blanket way.

In the case of a bookmark that really represents a file location
(and they are not all such, but the current case deals only with the
default handler and its file-access case, so it is probably OK in
this regard), it could be thought that the file name might
reasonably be added to `file-name-history'.  Why?  Because it is
very close to the idea of the user inputting the file name.

But it is not the same thing as entering the file name explicitly,
as minibuffer input.  And that alone is what `file-name-history'
(and all of the minibuffer histories) are for.  It makes sense, if
the user enters a bookmark name in the minibuffer, to add that
name to a bookmark-name history list.  But not to update any other
history lists by that action.

Again, though, it should be up to the individual command (i.e., its
designer, based on its purpose etc.) to decide this.  There should
be no blanket rule - certainly not maximizing adding file names to
the history.

The general guideline should be what I said above: Add to the current
minibuffer history only when the given name is in fact entered from
the minibuffer.  But that's a guideline, and any given command could
decide otherwise, e.g., could decide that it would be more helpful
to users to add some name that was not in fact entered.

We could also decide to have a user option that let users choose
whether to be lax or strict about respecting the guideline.  Then
commands could test that option and thus decide whether to add a
related file name to the history even when it was not entered.

Please do see the bug #12915 thread, for more info.  In particular,
as one important example, there is the case of commands that are
invoked by accessing menus, rather than via `M-x'.  IOW, by
menu-item name rather than by command name, and by menu rather
than by minibuffer.

IMO, there should be a user option governing whether those command
names get added to `command-history'.  (And I have such an option
in Icicles, for instance.)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]