[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: |
Wed, 16 Sep 2015 20:04:58 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Thunderbird/41.0 |
On 09/16/2015 04:31 PM, Stephen Leake wrote:
I found it convenient for building a project object, and for testing.
But it is otherwise not used in this patch.
Please build the project objects using the "recursive" approach.
Except that 'completing-read' does require exactly that. I did try to
prepend directories for uniquification; it doesn't work. Or at least it
would require major surgery on completing-read to make it work.
You might have to use a different `category' and set up a
`completion-category-overrides' entry that would only use
`partial-completion' as its style.
You'll be able input "/file", and it'll match "foo/bar/file.el". The
completion table will have to handle the `boundaries' action properly,
though.
Later, we can even add a new, more permissive style. We could use it in
other places as well.
On the other hand, if I understand it right, I can't type "test unit
foo", to see the unit test for foo.
It's not google search.
I'm sure you agree that web search is very handy.
Can you be more specific? What is the file name you are trying to
complete to?
Suppose I have ./test/unit/foo_test.rb and ./test/functional/foo_test.rb.
Typing 'unit/foo' or 'functional/foo' would return one or the other.
Note that trying to uniquify the paths automatically might create
abbreviations where the user would try to input a path segment fully
(not in this example, though).
One thing it should handle but doesn't yet; when presented with:
foo.el<bar> foo.el<baz> foo.el<car>
The user should be able to type <b to narrow to the first two.
Typing bar/foo is more natural than foo.el<bar. Also quicker.
As an added bonus, if you see an unfamiliar file, you'll see its full
relative path in the completion interface without having to open it.
There's already a project-find-file.
There are two similarly named functions; one interactive, the other
dispatching. EDE uses -impl suffix for the latter; that would work here.
If I'm not mistaken, project-find-file, as currently implemented, will
go away after you use completion tables as described above.
But if not, find-file-in-project is also an adequate name.
More importantly, the result of the completion is treated differently; the
default instance calls locate-file after rearranging the uniquification,
while the global instance calls ceded-gnu-global-call.
Why? If we've identified the requested file, let's just open it.
`completing-read' does _not_ return an absolute or unique path. See below.
Well, it could. I wonder if we shouldn't go at it this way:
project-file-completion-table will return a table which returns absolute
file (and directory) names.
find-file-in-project calls completing-read with that table. However, we
could have a completing-read-function (now, or add it at some later
time) which would display completions is some abbreviated fashion
(shortening the roots, basically).
As a drawback - it might clash with completing-read-function already
customized by the user. Not sure how to compose or prioritize them.
Alternatively, find-file-in-project could wrap the returned completion
table in some "abbreviating" one that abbreviates the project roots in
file paths when displaying them (and possibly abbreviates some file name
segments as well). Then, after the selection is made,
find-file-in-project simply expands the root abbreviation. Or, if some
segments can be abbreviated too, it polls the wrapping table to get the
original file path (so the table should maintain some correspondence cache).
Not sure if find-file-in-project should looks inside the whole
search-path; if so, replace "project roots" with "search dirs" above.
Yet another option is simply to make find-file-in-project search only
within the current project root.
This seems to be a good argument against using base file names, and in
favor of using full relative paths against project roots, combined
with abbreviated roots.
That would add significant clutter to the UI when filenames collide; you
often don't need the full path to a root to distinguish them.
You probably mean "don't collide". Yes, there will be some visual
overhead, but this approach is probably the most flexible WRT different
project structures, and the user can understand easily what's required
of them. Less so with foo.el<bar.
And in the global case, the elisp code has no idea what path global is
using; it must always call global to get an absolute path.
I don't understand. Can't Global return absolute file paths?
It would make sense to modify completing-read to be able to return
meta-information with the completion. I looked at that briefly, and I
have no idea how to go about it.
It must be doable, but we can manage without it.
You keep ignoring the fact that in some use cases, the available project
path information is already flat, and has to be converted to
recursive/ignores. I presented the AdaCore gpr file example.
Maybe it has to, but not in the API.
In addition, a mix of flat and recursive/ignore is convenient for users
constructing a path.
Please, let's avoid that kind of complexity in the API. The recursive
format is more powerful, so we should use just it.
- Re: find-file-project, (continued)
- Re: find-file-project, Stephen Leake, 2015/09/16
- Re: find-file-project, Stephen Leake, 2015/09/16
- Re: find-file-project, Stephen Leake, 2015/09/16
- Re: find-file-project, Dmitry Gutov, 2015/09/16
- Re: find-file-project, Stephen Leake, 2015/09/16
- Re: find-file-project, Dmitry Gutov, 2015/09/17
- project.el semantics, Stephen Leake, 2015/09/18
- Re: project.el semantics, Dmitry Gutov, 2015/09/18
- Re: project.el semantics, Stephen Leake, 2015/09/19
- Re: project.el semantics, Dmitry Gutov, 2015/09/19
- Re: find-file-project,
Dmitry Gutov <=
- Re: find-file-project, Stephen Leake, 2015/09/16
- Re: find-file-project, Dmitry Gutov, 2015/09/17
- Re: find-file-project, Stefan Monnier, 2015/09/16
- Re: find-file-project, Dmitry Gutov, 2015/09/17
- Re: find-file-project, Stefan Monnier, 2015/09/18
- Re: find-file-project, Dmitry Gutov, 2015/09/18
- Re: find-file-project, Stefan Monnier, 2015/09/19
Re: find-file-project, Eli Zaretskii, 2015/09/16