[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Unified project interface
From: |
Stephen Leake |
Subject: |
Re: Unified project interface |
Date: |
Thu, 30 Jul 2015 03:17:18 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (windows-nt) |
Dmitry Gutov <address@hidden> writes:
> On 07/29/2015 05:27 AM, Stephen Leake wrote:
>
>>> But you do specify "custom" locations for sal,
>>> sal_gtk and standard_common in the beginning, right? Then a smart
>>> enough tool could learn that information.
>>
>> I don't know what you mean by "learn"; the user writes the project file,
>> the tools read it.
>
> Figure out somehow, based on the project file and the contents of the
> file system, hopefully without asking the user more questions.
No need to "figure it out"; the search path for project files is right
there in the file:
for Project_Path use
("../../../org.stephe_leake.sal/build/release",
"../../../org.stephe_leake.gtk/build/release",
"../../../org.stephe_leake.makerules");
That's where the project files for sal, sal_gtk, standard_common are
found.
This is interpreted relative to the directory the project file is found
in.
> For instance, even if the project file gives no direct indication of
> which search-path elements are "proper" projects, some Elisp code
> could look inside each of those directories (and one level above,
> maybe) and see if there are project files in any of them. And those
> where there are, promote to project-roots as well.
> That might be harder for Ada, but should be totally doable for
> Java-based projects (if build.gradle doesn't provide that info).
For Ada project files, everything is crystal clear; anything mentioned
in "with" is a proper project; nothing else can be. No searching
involved.
Same for gradle; every build.gradle file defines a proper project;
nothing else does.
> But consider this: elisp-search-path is not ideal (the current project
> could be not in load-path).
I don't understand; the user sets load-path. If the user wants to use
project-* and xref-* functions with the current project, why is it not
in load-path?
That's just bad user configuration; no amount of elisp intelligence can
fix that.
xref-find-definitions for elisp relies on the code being loaded, so
using it without the code being loaded makes no sense.
>> It can still be up to the backend to decide whether they
>> are flat or require additional recursion.
>
> Err, that sounds silly. Why would you want not to recurse?
1) Because many Emacs functions don't recurse. For example, I'd like to add:
(defun project-find-file ()
"Prompt for a file name, find it on project-search-path."
(interactive)
(let ((filename
(completing-read
"file: "
(apply-partially
'locate-file-completion-table
(project-search-path (project-current))
nil))))
(find-file (locate-file filename (project-search-path (project-current))
nil))))
This works fine with "load-path" instead of "project-search-path". But
it won't work unless project-search-path is flat;
locate-file-completion-table and locate-file do not recurse.
2) As I've mentioned before, not recursing allows computing the set of
included/excluded directories once, instead of computing it again on
each recursion.
3) Because some tools provide and expect a flat search path (AdaCore
tools, gcc include path, emacs load-path, compilation-search-path,
ff-search-directories).
It is not at all clear how to convert a flat path into a recursive path
with ignores; the solution you have for elisp load-path is a kludge,
and could easily be wrong for some users.
> The current xref-collect-matches implementation unconditionally
> recurses, and it doesn't seem particularly useful to create a variant
> that doesn't.
The backends I'm aware of require flat paths (no recursion). So unless
some plausible backend actually requires recursion, it makes more sense
to assume recursion is not required.
>> Locations are tied other things besides cross-reference; cross-reference
>> is just one way of producing a list of locations.
>>
>> find-regexp is another way.
>>
>> compilation errors is another way.
>>
>> All of those could use a common location API. 'project' is one place to
>> put it; it could be in its own 'location' namespace.
>
> I suppose you're right. But until we have a unified location API
> (which I wouldn't count on appearing anytime soon), xref is the better
> place.
>
> xref-location lives there, and it's the best purpose-agnostic location
> class that we have now.
So move it to "location" instead of "xref". The longest journey starts
with one step ...
--
-- Stephe
- Re: Unified project interface, (continued)
- Re: Unified project interface, Dmitry Gutov, 2015/07/28
- Re: Unified project interface, Stephen Leake, 2015/07/28
- Re: Unified project interface, Dmitry Gutov, 2015/07/28
- Re: Unified project interface, Stephen Leake, 2015/07/28
- Re: Unified project interface, Dmitry Gutov, 2015/07/28
- Re: Unified project interface, Dmitry Gutov, 2015/07/28
- Re: Unified project interface, Stephen Leake, 2015/07/28
- Re: Unified project interface, Dmitry Gutov, 2015/07/28
- Re: Unified project interface, Stephen Leake, 2015/07/28
- Re: Unified project interface, Dmitry Gutov, 2015/07/29
- Re: Unified project interface,
Stephen Leake <=
- Re: Unified project interface, Dmitry Gutov, 2015/07/30
- Re: Unified project interface, Stephen Leake, 2015/07/31
- Re: Unified project interface, Dmitry Gutov, 2015/07/31
- Per-language project-search-path, was: Re: Unified project interface, Dmitry Gutov, 2015/07/31
- xref display and multiple locations, was: Re: Unified project interface, Dmitry Gutov, 2015/07/29