From: Eli Zaretskii <eliz@gnu.org>
To: Drew Adams <drew.adams@oracle.com>
Cc: cyd@gnu.org, 12915@debbugs.gnu.org
Subject: bug#12915: 24.2.50; Visiting a file via drag-and-drop should add it to the history ofvisited files
Date: Sun, 13 Jan 2013 19:31:34 +0200 [thread overview]
Message-ID: <838v7xrnux.fsf@gnu.org> (raw)
In-Reply-To: <95D0D9D79F6C43FC8DA324988AFF23E0@us.oracle.com>
> 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.
next prev parent reply other threads:[~2013-01-13 17:31 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-17 13:07 bug#12915: 24.2.50; Visiting a file via drag-and-drop should add it to the history of visited files Dani Moncayo
2012-11-17 19:07 ` Glenn Morris
2012-11-17 21:37 ` Dani Moncayo
2013-01-02 9:16 ` Dani Moncayo
2013-01-12 8:25 ` Chong Yidong
2013-01-12 13:18 ` Stefan Monnier
2013-01-12 14:30 ` martin rudalics
2013-01-12 16:54 ` Stefan Monnier
2013-01-12 18:01 ` martin rudalics
2013-01-12 18:02 ` bug#12915: 24.2.50; Visiting a file via drag-and-drop should add it to the historyof " Drew Adams
2013-01-12 18:01 ` bug#12915: 24.2.50; Visiting a file via drag-and-drop should add it to the history ofvisited files Drew Adams
2013-01-12 18:32 ` Eli Zaretskii
2013-01-12 22:43 ` Drew Adams
2013-01-13 17:31 ` Eli Zaretskii [this message]
2013-01-13 18:55 ` Drew Adams
2013-01-12 17:59 ` Drew Adams
2013-01-13 9:21 ` bug#12915: 24.2.50; Visiting a file via drag-and-drop should add it to the history of visited files Andreas Röhler
2013-01-13 16:28 ` Eli Zaretskii
2013-01-13 9:56 ` Juri Linkov
2013-01-13 10:15 ` Dani Moncayo
2013-01-13 14:25 ` Stefan Monnier
2013-01-13 17:13 ` bug#12915: 24.2.50; Visiting a file via drag-and-drop should add it to the history ofvisited files Drew Adams
2013-01-13 20:24 ` Dani Moncayo
2013-01-13 22:45 ` Stefan Monnier
2013-01-13 19:52 ` bug#12915: 24.2.50; Visiting a file via drag-and-drop should add it to the history of visited files Dani Moncayo
2013-01-13 22:34 ` Stefan Monnier
2013-01-13 17:13 ` bug#12915: 24.2.50; Visiting a file via drag-and-drop should add it to the history ofvisited files Drew Adams
2013-01-14 7:52 ` bug#12915: 24.2.50; Visiting a file via drag-and-drop should add it to the history of visited files Juri Linkov
2013-01-14 8:18 ` Dani Moncayo
2013-01-14 15:18 ` Stefan Monnier
2013-01-14 15:50 ` bug#12915: 24.2.50; Visiting a file via drag-and-drop should add it to the history ofvisited files Drew Adams
2013-01-14 15:45 ` Drew Adams
2013-01-15 9:57 ` Juri Linkov
2013-01-15 15:07 ` Drew Adams
2013-01-13 16:35 ` bug#12915: 24.2.50; Visiting a file via drag-and-drop should add it to the history of visited files Eli Zaretskii
2013-01-13 17:14 ` bug#12915: 24.2.50; Visiting a file via drag-and-drop should add it to the historyof " Drew Adams
2021-07-18 19:21 ` bug#3909: 23.1.50; Drag drop events in command history? Lars Ingebrigtsen
2021-07-18 21:08 ` bug#12915: [External] : bug#12915: " Drew Adams
2021-07-18 22:32 ` bug#3909: " Juri Linkov
2021-07-18 22:50 ` Lars Ingebrigtsen
2021-07-19 15:24 ` Juri Linkov
2021-07-19 15:51 ` bug#3909: " Lars Ingebrigtsen
2021-07-19 21:57 ` Juri Linkov
2021-07-20 11:48 ` 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=838v7xrnux.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=12915@debbugs.gnu.org \
--cc=cyd@gnu.org \
--cc=drew.adams@oracle.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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.