all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Juri Linkov'" <juri@jurta.org>, "'Dani Moncayo'" <dmoncayo@gmail.com>
Cc: 'Chong Yidong' <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: Mon, 14 Jan 2013 07:45:11 -0800	[thread overview]
Message-ID: <65F6EBA42246485393472446D6597C96@us.oracle.com> (raw)
In-Reply-To: <87d2x842ws.fsf@mail.jurta.org>

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






  parent reply	other threads:[~2013-01-14 15:45 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
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 [this message]
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=65F6EBA42246485393472446D6597C96@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=12915@debbugs.gnu.org \
    --cc=cyd@gnu.org \
    --cc=dmoncayo@gmail.com \
    --cc=juri@jurta.org \
    /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.