[Top][All Lists]

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

Re: cl-defgeneric vs random funcall in project.el

From: Dmitry Gutov
Subject: Re: cl-defgeneric vs random funcall in project.el
Date: Thu, 30 Jul 2015 20:16:13 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0

On 07/30/2015 06:29 PM, Stephen Leake wrote:

The point of a "project backend" is that it knows _everything_ about the
project. No stray hooks for users to pervert things.

The problem is I (and others) have a lot of Elisp projects which don't adhere to some particular structure. No particular project files, aside from a .git repo, and maybe Makefile, or maybe some other -file.

It's not even easy to identify it: maybe there are some .el files in the root directory, but they might all be in a subdirectory.

I want to support this use case.

I would write the vc implementation of project-search-path to return a
flat list of all the directories under the vc root.

The flat list is really out of the question. It really goes against my intuition and every project backend will have to implement the logic of producing this flat list based on some roots and a list of ignores.

We won't be able to use rgrep on the resulting directories, but we'd still have to handle ignored files.

I'd rather project-ignores was powerful enough to describe the majority of cases, and xref-find-regexp knew how to interpret that list.

Right. The elisp project backend is incomplete.

It's not a backend. Like described above, it would be hard to even write a reasonably efficient project-find-functions element for such a backend. What will it do? Recursively scan the VC repo for .el files?

That's one problem with using two dispatching mechanisms; it's too easy
to get mixtures of incomplete implementations that "seem to work".

I'd call it "composability". :)

reply via email to

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