[Top][All Lists]

[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 07:41:30 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Thunderbird/41.0

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_

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

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

I see, thanks.

(defvar project-emacs
   (let ((cedet-root (file-name-directory (locate-file "cedet.el" load-path))))
        (concat cedet-root "ede")
        (concat cedet-root "semantic")
        (concat cedet-root "srecode"))

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.


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

instances might want to bind completion-ignore-case or

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]