Re: find-file-project

[Dmitry Gutov <dgutov@yandex.ru>]

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.