[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: |
Mon, 27 Jan 2014 07:11:58 -0800 (PST) |
> I'm on Drew side here, I think a one-by-one approach is better,
> whether there is a general mechanism or not (yet).
>
> Since there is no strong objection for fixing the bookmark-jump
> case, and since it's trivial to migrate this fix to a general
> solution when we'll have one, I'm willing to apply the fix if
> no-one objects in a week.
I did not object to the idea out of hand, and I agreed that
there are arguments in its favor (for `bookmark-jump').
However, to be clear: There is no hurry for this command to act
like that, and my preference would be to *not* make this change
now for that one command, and instead to wait until we address
the issue more generally.
E.g., a user option to give users some control over this.
The file-name history is, after all, _their_ history.
Starting down this road is not a great idea without a general
plan. Until now, minibuffer histories are designed to reflect
only text _actually input from the minibuffer by the user_.
To change that design decision so that it becomes only a
guideline, which gets modulated by other influences (e.g., the
individual command; one or more user options overrule; etc.),
we should have a general plan for where we're headed - a new
design.
So I do not object strongly, but I think it is a bad idea
to set a precedent this way. It is better to discuss the
general issue on emacs-devel. And there certainly is no
hurry for this, when it comes to `bookmark-jump'.
If you really want to do this now for `bookmark-jump', then
a compromise could be to add a user option just for that,
i.e., in bookmark.el. Then, if and when a more general
design is adopted, that option could be removed in favor of
a more general option.
That would let users retain the current `bookmark-jump'
behavior or not, as they prefer.
- 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/24
- bug#16542: 24.3.50; When finding a file via a bookmark, that file is not part of file-name-history, Dani Moncayo, 2014/01/25
- bug#16542: 24.3.50; When finding a file via a bookmark, that file is not part of file-name-history, Drew Adams, 2014/01/25
- bug#16542: 24.3.50; When finding a file via a bookmark, that file is not part of file-name-history, Bastien, 2014/01/27
- bug#16542: 24.3.50; When finding a file via a bookmark, that file is not part of file-name-history,
Drew Adams <=
- bug#16542: 24.3.50; When finding a file via a bookmark, that file is not part of file-name-history, Bastien, 2014/01/27
- bug#16542: 24.3.50; When finding a file via a bookmark, that file is not part of file-name-history, Drew Adams, 2014/01/27
- bug#16542: 24.3.50; When finding a file via a bookmark, that file is not part of file-name-history, Juri Linkov, 2014/01/28
- bug#16542: 24.3.50; When finding a file via a bookmark, that file is not part of file-name-history, Stefan Monnier, 2014/01/28
- bug#16542: 24.3.50; When finding a file via a bookmark, that file is not part of file-name-history, Juri Linkov, 2014/01/29
- bug#16542: 24.3.50; When finding a file via a bookmark, that file is not part of file-name-history, Bastien, 2014/01/29
- bug#16542: 24.3.50; When finding a file via a bookmark, that file is not part of file-name-history, Stefan Monnier, 2014/01/29
- bug#16542: 24.3.50; When finding a file via a bookmark, that file is not part of file-name-history, Drew Adams, 2014/01/28