Re: find-file-project

[Dmitry Gutov <dgutov@yandex.ru>]

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.

> And as we also discussed earlier, for _some_ projects, flat paths _are_
> optimal.

That just means that the respective backends will store user settings in 
a certain fashion. There's no need to add functional duplication to the 
project API.

> What is the downside of a few dozen lines of code to support a few
> projects?

Implementation uncertainty and API complexity.

>> Why not just implement completion on file paths relative to the
>> project root?
>
> For Emacs elisp, there is no single root, except perhaps "/".

That's a decent argument. But then, when there are several roots, you 
could uniquify just their names, and prepend them to file names.

Your way may be better, but I'm not too sure yet.

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

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

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

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

>>> 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. Just use 
the current format.

> I've also implemented ede-find-file, which dispatches to the
> semantic-symref global backend. Next patch.

Is there a reason to keep the gtags backend, then?

> I've already tested it. I guess if you mean if I want others to test it.

Yes.

> I was hoping this patch would be enough.

It isn't. Sorry.

>> I don't think each implementation should do its own completing-read.
>> Rather, they should just return the completion table from a generic
>> method. E.g. (cl-defmethod project-file-completion-table ...).
>
> For the default find-file-in-project, that would require computing the
> flat path and the predicate on each use of the completion table.

Why? The generic function could just as well return 
(completion-table-with-cache #'find-file-complete-global-table).

> Other
> instances might want to bind completion-ignore-case or
> completion-regexp-list.

completion-ignore-case is no business of theirs. Instead of 
completion-regexp-list, they can use a completion table with predicate.

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

> I don't follow; the completion does not need to be sorted. This code is
> dealing with the result of completion.

I see.

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

> It's on a par with the existing EDE "generic" projects for vc tools. And
> with the existing project-vc.

project-vc is an minimum-viable-product for those who don't bother 
configuring anything else. There's no reason to have many of them.

> I don't follow; what file names are being shortened? On the contrary,
> they are being lengthened, with enough directory names to make them unique.

Either way, you're trying to same on typing during completion. 
completion-at-point helps with that as well.

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