Re: find-file-project

[Stephen Leake]

Dmitry Gutov <address@hidden> writes:

> On 09/16/2015 05:49 AM, Stephen Leake wrote:
>
>> Only code that needs flat paths uses them. As we discussed earlier, we
>> can either compute the flat path, and do completion on it, or compute
>> the flat path while doing completion.
>
> If you absolutely need flat paths for completion here, just having the
> function that do one-way conversion should suffice. There's no need
> for project-flat-to-recursive-ignores, for instance.

I found it convenient for building a project object, and for testing.
But it is otherwise not used in this patch.

>>> The user could input a base file name, if they like, and TAB would
>>> expand it to one of the relative paths if it's unique, or allow them
>>> to input a directory. You won't need any other uniquification then.
>>
>> That requires the user to know what directory the file is in, as
>> find-file completion does now.
>
> It doesn't - you complete using the files list you've collected during
> the initial walk, and you match the typed file name against it.
> There's no reason to require that the input matches the beginning of
> the string.

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.

>> Using a flat path avoids that. I find it quite useful to just type
>> "locate", and immediately see that there are two choices, one of which I
>> was unaware of.
>
> 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.

Can you be more specific? What is the file name you are trying to
complete to?


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.

>> On the other hand, what you are describing is pretty much what
>> find-file-project does. Have you tried it?
>
> Not yet. I will, when you push it to the feature branch.

Ok, I'll do that.

>>> Maybe call it find-file-in-project?
>>
>> That does sound better.
>
> Or just call the command project-find-file. It's inside project.el,
> after all.

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.

>>>> The patch also adds small projects for elisp and global, to show that
>>>> this approach works for multiple backends.
>>>
>>> I don't see the elisp backend.
>>
>> Oops; that got left out of the patch. This code is supposed to be in
>> project.el:
>
> I see, thanks.
>
>> (defvar project-emacs
>>    (let ((cedet-root (file-name-directory (locate-file "cedet.el" 
>> load-path))))
>>      (project-elisp-make
>>       (project-recursive-ignores-to-flat
>>        (list
>>         (concat cedet-root "ede")
>>         (concat cedet-root "semantic")
>>         (concat cedet-root "srecode"))
>>        nil)
>>       )))
>
> And this is ridiculous. Emacs obviously isn't a "flat" project. 

I don't know what you mean by "a flat project".

load-path is neither purely flat (cedet requires recursion) nor purely
recursive (it has both emacs/lisp and emacs/lisp/progmodes etc). So it
has to be converted one way or another.

I did try to use the recursive approach; this seemed simpler.

I'll use the recursive approach in the feature branch, for a true
comparison.

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

>> A better way to accomplish this would be to somehow encode the full
>> directory path in the completion result, but I didn't find a way to do
>> that. In particular, text properties are not returned from completion.
>
> 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.

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.


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.

>> I guess you are asking for some rationale. This code allows converting
>> between the two equivalent representations of search paths;
>> recursive/ignores and flat. As we have discussed before, there are cases
>> where both of these conversions are useful.
>
> Not really. You don't need the ability to convert from flat paths to
> recursive if the project API consistently uses the "recursive" format.
> All data is already in 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.

In addition, a mix of flat and recursive/ignore is convenient for users
constructing a path.

This does need some unit tests for the conversion functions.

-- 
-- Stephe