[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: project.el semantics
From: |
Dmitry Gutov |
Subject: |
Re: project.el semantics |
Date: |
Sun, 22 Nov 2015 19:13:48 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Thunderbird/42.0 |
On 11/22/2015 06:55 PM, John Wiegley wrote:
I'm still not sure why this means we need to encode restrictions within
project.el, rather than, say, in Ada mode, or whichever other mode is
providing information to project.el for the traversal of its related elements.
I don't know what restrictions for Ada mode you have in mind. And how we
might be able to mandate them, if not though project.el API.
I want as much freedom of expression as we can get away with, so long as the
default and expected use cases remain easily within reach.
Freedom has a cost. In particular, if directories can be recursive or
not, *each* API consumer will have to pay the price of supporting both
ways. Like I already said, xref-collect-matches will have to grow
another code path. And every other similar function will have to do that
too.
I have mentioned this multiple times already. Why don't we stop going in
circles?
I feel, though, as if I've lost my grip on the vision for this project again.
Maybe that's because you're only thinking in generals, and not examining
the practical applications. Like the function mentioned above, and how
it will have to change to accommodate your freedom.
As I understand it, it has two main components:
1. Ways to determine members of a project.
2. Ways to usefully apply this information.
I think our discussion so far have been in the area of #1 only, right? And is
that because we're stuck on how to define membership?
From where I'm standing, it's because a certain person keeps derailing
the discussion into making the API closer to how a "list of directories"
usually works in Ada.
And not because it's necessary for functionality (as we've discussed,
recursive dirs + ignores can adequately describe a non-recursive set of
dirs), but simply because it's convenient for a particular minority use
case.
As long as, at the level of project.el, membership can optionally be a list of
"collection functions", this would allow near infinite expressiveness while
not detracting from the standard use cases of recursive and non-recursive
directory traversals.
That's too vague. How will your "collection functions" mesh with using
"find", so that most operations can stay performant in large projects?
I don't think we gain anything by "baking in" what membership means, and
disallowing flexible definitions.
On the subject of what we gain, see above.
Such a road leads us to continuing to have
to extend and hack project.el's interface, as users run into the limits of
what it can express.
Again: recursive dirs + ignores can adequately describe a non-recursive
set of dirs.
Which Stefan already has done with ada-mode. We shouldn't
even be discussing ada-mode! There is a simple design path that can allow
Stefan to define his project contents however he wants. Such questions should
not even be an issue at this level of the API.
If Stephen wants to define his project contents however he wants,
without regard for any consumers, that cannot fit in any stable API
definition.
- Re: project.el semantics, (continued)
- Re: project.el semantics, Dmitry Gutov, 2015/11/12
- Re: project.el semantics, Dmitry Gutov, 2015/11/18
- Re: project.el semantics, John Wiegley, 2015/11/20
- Re: project.el semantics, Stephen Leake, 2015/11/21
- Re: project.el semantics, Stephen Leake, 2015/11/21
- Re: project.el semantics, John Wiegley, 2015/11/22
- Re: project.el semantics, Dmitry Gutov, 2015/11/22
- Re: project.el semantics, John Wiegley, 2015/11/22
- Re: project.el semantics, Dmitry Gutov, 2015/11/22
- Re: project.el semantics, John Wiegley, 2015/11/22
- Re: project.el semantics,
Dmitry Gutov <=
- Re: project.el semantics, John Wiegley, 2015/11/22
- Re: project.el semantics, John Wiegley, 2015/11/22
- Re: project.el semantics, Dmitry Gutov, 2015/11/22
- Re: project.el semantics, Steinar Bang, 2015/11/23
- Re: project.el semantics, Dmitry Gutov, 2015/11/23
- Re: project.el semantics, Stephen Leake, 2015/11/23
- Re: project.el semantics, Dmitry Gutov, 2015/11/23
- Re: project.el semantics, Stephen Leake, 2015/11/22
- Re: project.el semantics, Dmitry Gutov, 2015/11/22
- Re: project.el semantics, Richard Stallman, 2015/11/22