bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#12915: 24.2.50; Visiting a file via drag-and-drop should add it to t


From: Eli Zaretskii
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

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





reply via email to

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