unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Dani Moncayo <dmoncayo@gmail.com>, Bastien Guerry <bzg@altern.org>
Cc: 16542@debbugs.gnu.org
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)	[thread overview]
Message-ID: <af92ac83-36ec-4484-9b9c-00cba832b98c@default> (raw)
In-Reply-To: <CAH8Pv0gOk+WFHcy6dLu6SJ0agf=rWe5SqqaOyffE7QbpYtAHYw@mail.gmail.com>

> 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	other threads:[~2014-01-25  8:42 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-24 21:45 bug#16542: 24.3.50; When finding a file via a bookmark, that file is not part of file-name-history Bastien Guerry
2014-01-25  8:19 ` Dani Moncayo
2014-01-25  8:42   ` Drew Adams [this message]
2014-01-27 11:29     ` Bastien
2014-01-27 15:11       ` Drew Adams
2014-01-27 15:26         ` Bastien
2014-01-27 17:31           ` Drew Adams
2014-01-28  7:28             ` Juri Linkov
2014-01-28 13:28               ` Stefan Monnier
2014-01-29  9:10                 ` Juri Linkov
2014-01-29 10:43                 ` Bastien
2014-01-29 13:58                   ` Stefan Monnier
2014-01-28 16:20               ` Drew Adams
2020-08-25 10:57 ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=af92ac83-36ec-4484-9b9c-00cba832b98c@default \
    --to=drew.adams@oracle.com \
    --cc=16542@debbugs.gnu.org \
    --cc=bzg@altern.org \
    --cc=dmoncayo@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).