[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unified project interface

From: Dmitry Gutov
Subject: Re: Unified project interface
Date: Sat, 1 Aug 2015 15:40:16 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0

On 08/01/2015 12:50 PM, Stephen Leake wrote:

As such, it will require a separate code path in xref-collect-matches
and an alternative for xref--rgrep-command.

Or they could abort; that would be ok while we are experimenting. It may
be that one or the other will turn out to be The Right Way.

That's not helpful. Of course we want the API be straightforward and usable for as many callers as possible. It's the main goal.

I'm not sure how The Right Way would supposedly present itself.

A backend that uses flat paths doesn't have to use those functions. Or,
the people writing that backend can modify them if that seems better
than putting similar code elsewhere. That would be part of the cost of
that design decision.

It's a high cost.

If the author of such backend intends to reimplement or rewrite every feature like that, they can just as well not bother with implementing the Project API. As you can see, there's not much code in project.el, so they won't miss much if they don't value interoperability.

This could be implemented with a root projects type:

(cl-defstruct (projects)
   user-search-path ;; list of directories added to project-search-path
   user-ignores ;; list of ignores added to project-ignores
   ;; if non-nil, project-search-path is treated as recursive in all usees

That doesn't tell me what values project-search-path would return, for every kind of configuration. That's the important part.

Is that "ugly"?

Depends on how you feel about double negatives. There should be just one way to express whether a given directory should be traversed recursively.

(cl-defstruct (projects)

would be one option for the implementation, but what would it mean for the API? If we have both project-flat-search-path and project-recursive-search-path as accessors, there's high probability that some functions will only look up and handle one of them. That's bad.

The /** syntax is rather nifty. But why do you propose to have it and
MAKE-RECURSIVE at the same time? We could just interpret /** as the
recursive marker. Then the result could be a list of strings.

Because you never need both. If you are used to using recursive paths,
adding ** in the path to tell the code that will seem odd. So it seems
best to have an explicit flag.

The user could specify the paths in any way they like, are used to, etc. What's important is what the project backend returns in project-search-path.

I've just started to write about this... Yes indeed, I think every
flat structure can be translated into path/to/dir, plus path/to/dir/*/
in the ignores. The translation function shouldn't take too much work
to write.

The reverse is also true; it is possible to convert recursive
path/ignores into flat path/ignores.

Not without drawbacks. First, it's more computationally intensive (Emacs would have to traverse the actual directory tree). Second, like I mentioned before, that loses information: in particular, we won't know which directories were the root ones.

There's no need to produce the list of ignores manually.

Only if you ignore the use cases I posted. There are situations where
the algorithm will not do what the user wants.

What algorithm? I don't see why you can't write an algorithm that will both handle flat directories via ignores, as well as honor the user's wishes.

The fact that you don't like them does not mean they are not valid.

Would it be such a problem to provide 'project-add-ignores'?

I don't understand why you would state this question here? It doesn't seem relevant.

Me, and many other teams at NASA - structures similar to the above,
where the non-included directories can also be release version,
debug/release options, target hardware/os option, compiler
vendor/version, etc.

There can be different opinions about this.

Yes, precisely. And Emacs core should not be enforcing any opinions!

Err, some opinions are worth being enforced. But anyway, the Ada project backend can behave any way you wish, in this respect.

Both still use xref for display. The location values aren't consumed
by anything else. So that's just one place.

They both display locations. The code that displays locations should
also be in the locations namespace, not the xref one.

What's left for xref, then? Most of the code there deals with displaying xrefs in the buffer.

reply via email to

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