[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: find-file-project
From: |
Dmitry Gutov |
Subject: |
Re: find-file-project |
Date: |
Sat, 9 Jan 2016 20:11:01 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:43.0) Gecko/20100101 Thunderbird/43.0 |
On 01/09/2016 03:18 PM, Stephen Leake wrote:
What is the alternative?
Only the user knows which directories in load-path should be treated
recursively.
I don't see the harm in treating all of them recursively.
That assumes only CEDET is handled recursively; if I add another project
that has recursive dirs, I'll have to add that to this function.
This is unnecessarily complex, I think.
If "locate.el" has duplicates, but I don't know that, then I start by
typing "loc", and the completion shows both completions, with
disambiguating suffix.
And here's the problem: the user is obliged to refer to your list of
disambiguated entries, to pick the right one. It's harder to guess, in
advance, what I can type. Which makes the process slower than it has to be.
If the first one is the one I want, I hit <ret>. otherwise I hit <right>
<ret>.
<right>? Are you using ido-mode? I was discussing how it looks with the
default completion mechanism.
If you're using icomplete-mode, or ivy-mode, you can also M-x
project-find-file now, type locate.el, and pick either of the two
matches quickly, using C-./C-, or C-n/C-p (respectively) followed by RET.
That's the same pattern needed to distinguish "filter.el" from
"filters.el", except the disambiguation in the first case happens to
include directories.
Right, and in any case, I can admit that for files with unique base
names your approach yields fewer false positives than fuzzy matching
across full relative names.
On the other hand, I find being able to see the relative names rather
useful. E.g. I may remember the actual base file name incorrectly;
looking at the directory the file with the given name is in, can help me
avoid the wrong choice and recall the right name.
If we used prefix directories, there might be a problem; depends on the
details.
IME, this approach works fairly well.
On the other hand, with your implementation, I'm required to type
"ede/locate.el" vs "locate.el" to find these two files. So I have a
problem; I don't want to have to memorize all the files in ede, srecode,
and semantic!
One ends up memorizing directory names anyway, in the course of working
on a project.
But no, you don't have to memorize them: you type 'locate.el', press TAB
(or RET), and see the directory names in the completions list.
- Re: find-file-project, (continued)
- Re: find-file-project, Stefan Monnier, 2016/01/06
- Re: find-file-project, Stephen Leake, 2016/01/07
- Re: find-file-project, Dmitry Gutov, 2016/01/07
- Re: find-file-project, Dmitry Gutov, 2016/01/07
- Re: find-file-project, Stephen Leake, 2016/01/07
- Re: find-file-project, Dmitry Gutov, 2016/01/07
- Re: find-file-project, Stephen Leake, 2016/01/08
- Re: find-file-project, Dmitry Gutov, 2016/01/08
- Re: find-file-project, Stephen Leake, 2016/01/09
- Re: find-file-project,
Dmitry Gutov <=
Re: find-file-project, John Wiegley, 2016/01/07
- Re: find-file-project, Dmitry Gutov, 2016/01/07
- Re: find-file-project, Stefan Monnier, 2016/01/08
- Re: find-file-project, Dmitry Gutov, 2016/01/19
- Re: find-file-project, Stefan Monnier, 2016/01/19
- Re: find-file-project, Dmitry Gutov, 2016/01/19
- Re: find-file-project, Stefan Monnier, 2016/01/19
- Re: find-file-project, Dmitry Gutov, 2016/01/19