[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: progmodes/project.el and search paths
From: |
Dmitry Gutov |
Subject: |
Re: progmodes/project.el and search paths |
Date: |
Wed, 12 Aug 2015 12:28:07 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0 |
On 08/12/2015 03:49 AM, Eric Ludlam wrote:
Every project is indeed different. A system that needs to load lisp
code needs to protect against ill formatted lisp code. Putting this in
a core system will help implementations from all creating the same
latent bug. If project.el isn't going to provide detection services,
then it won't need this feature.
Probably not, at least not at first.
In EDE, a project adds itself to the list of possible projects. Each
project classifies itself by a term that places itself in one of three
bins, and hopefully those bins don't conflict. ;)
Not to dismiss the detailed approach, but the user could reorder the
elements in project-find-functions as well, if the default order is not
to their liking.
What you're describing would be an improvement, but not of the
revolutionary kind. And I'm not really sure how to fit the
classification together with project-find-functions.
Right. Each project implementation needs to update their data from the
file system their own way. If there are generic development menus, it
would be helpful for the user to have one way to update project meta
data regardless of which type of implementation is active.
I'd rather user never had to do that at all.
* "Project Local Variables" look very similar to project metadata.
They are a type of meta data that let users provide extended behavior to
the project.
That sounds fine in theory, but we need a more concrete application.
Your Projectile example, for instance, would work just as well if it
didn't set the "project local variables" via the project API, and just
stored the information in its internal storage.
I will need to look at your search path concept more. Are there
multiple paths for different purposes?
No, just this one. Adding other paths will need more justification.
Several of these tools have an 'update the current tags file' type mode
you can get at. I don't recall if I wrapped that up with a handy
function or not.
That would be nice. But then you don't need any extra information about
the current project to do that, just knowing how to find the file and/or
call the tool.
In that case, it shouldn't need anything new in the project API. Not
even how to find the root, maybe (just use locate-dominating-file,
especially when there are several tags files in the project).
The key concept is that a project is rarely just one single activity.
Usually there are doc activities, code activities, build system
activities. Some projects have Java activities, and native C++
activities. All these different things are for a common goal, and often
there is a common lingo between them. I represent that lingo as 'tags'
in Semantic, and it enables you to 'copy' a tag which includes the meta
data around the name and 'paste' it into a buffer of a different
language.
That sounds like it needs a parser to work well. xref tries to handle it
as "identifier at point", but we'll have to see whether the different
implementations will include context information in it (via text
properties).
The only useful one there can turn a lisp tag into a texi
@defun block, but you could imagine a way to update your java native
methods bidirectionally. The project knows how to link these systems
together, such as finding the right doc for your Lisp code.
For one thing, writing documentation separately from sources is an alien
idea to me (and for other Ruby, Java or JS programmers, I think). So
this kind of information may need to be exposed as an optional service.
Language specificity was key for me because of the way mode-local works,
and how each language had customized behavior for the parsing tools. I
tended to focus on language specific accurate behaviors, and not generic
potentially inaccurate features. For example, smart completion vs
dabbrevs.
I like smart completion, but by tying it to projects we'd discount the
less accurate implementations that are still useful. On the other hand,
a package that implements project handling can add its own, accurate
completion functions as well.
As noted somewhere, symref had a way of converting modes to patterns. I
had to ask around, but eventually got something pretty good.
It didn't work well for Ruby files initially, so I had to add the
respective entries to semantic-symref-filepattern-alist. I'm sure there
are languages out there that are still not covered.
I'd be glad if I could stop maintaining parts of EDE because it became
part of some core system. It is still unclear to me where the
boundaries lie. I'm not sure where a patch would be helpful yet. My
hope is that my document would help you define the bounds of project.el
based in a set of terms we can both agree to. It would then be obvious
how I could help by donating pieces of EDE as needed.
My understanding of EDE is if there are tools that would be worth
porting, they would need to be rewritten on top of more general methods,
and would probably need rethinking.
My recommendation for you is to perhaps not reply to individual
clarifications above, but perhaps define where you think project.el fits
into the whole using whatever you like from my doc, and that would help
us focus the conversation on the boundary, and not on random things I
invented that aren't close to the boundary.
I'll try to do something like that in the foreseeable future. But
really, from where I'm standing, the question is not how to decide the
list of features, but how to implement each particular feature in a way
that would make sense for as many project types as possible.
- Re: progmodes/project.el and search paths, (continued)
- Re: progmodes/project.el and search paths, Stephen Leake, 2015/08/04
- Re: progmodes/project.el and search paths, Dmitry Gutov, 2015/08/04
- Re: progmodes/project.el and search paths, Stephen Leake, 2015/08/05
- Re: progmodes/project.el and search paths, Dmitry Gutov, 2015/08/05
- Re: progmodes/project.el and search paths, Stephen Leake, 2015/08/06
- Re: progmodes/project.el and search paths, Dmitry Gutov, 2015/08/07
Re: progmodes/project.el and search paths, Eric Ludlam, 2015/08/04