emacs-devel
[Top][All Lists]
Advanced

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

Re: progmodes/project.el and search paths


From: Eli Zaretskii
Subject: Re: progmodes/project.el and search paths
Date: Wed, 05 Aug 2015 19:31:09 +0300

> Cc: address@hidden
> From: Dmitry Gutov <address@hidden>
> Date: Wed, 5 Aug 2015 18:36:08 +0300
> 
> On 08/05/2015 06:08 PM, Eli Zaretskii wrote:
> 
> > If EDE finds this useful, what doubt is there that other Lisp programs
> > will?  How many examples do we need before we decide that a specific
> > trait of a project is "useful"?  I say one is enough (sometimes more
> > than enough).
> 
> A trait should be useful *and* fairly common.

It's common, just look at any IDE out there.

> Do you see someone in a hurry to rewrite EDE on top of project.el? I 
> don't. So we have zero potential consumers so far.

Like I said, I consider this kind of arguments irrelevant for
developing infrastructure.  Either it's important to develop
infrastructure for accessing project traits, or it isn't.  If it is
(and I gather you decided it is), then the infrastructure should IMO
be reasonably complete.

> >> Short of that, I can't think of a non-EDE elisp program that would want
> >> to know about targets. There might be one someday; we can extend
> >> project.el then.
> >
> > That's exactly my problem: I find such an approach surprising, to say
> > the least, when building such basic infrastructure.
> 
> On the other hand, it wastes less time on speculative features, and the 
> API is almost guaranteed to turn out better in the end.

Not IME.  What I saw more than once is unfinished infrastructure that
no one wanted to continue developing, because the person(s) who
started moved on without arriving at some reasonably complete
component.

> > I think there
> > should be small doubt that access to project documentation, including
> > its build command, is one of these basics, because every project has
> > that.
> 
> I don't even know what "access to project documentation" means. Is it 
> just the build command? Or the paths of resulting files? Or their 
> formats? Or an index? Or a way to display them?

There are a lot of IDEs out there to learn from and get answers to all
these questions very quickly.

IME, doing that kind of research is always part of any infrastructure
development.  It sounds like you would prefer waiting till someone
comes up and teaches you/us all these answers, or presents clear
requirements that allow you to formulate those answers, but IME that
seldom happens, because people who already went through that research,
or gained the answers from personal experience, are a few and far
in-between, and they are unlikely to line up to help us, of all the
projects.  I went through such an experience myself years ago, when I
started to work on bidirectional display.

Anyway, I think my views on this are clear, so I think it's time for
me to stop arguing about this.



reply via email to

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