Re: progmodes/project.el and search paths

[Eli Zaretskii <eliz@gnu.org>]

> From: Stephen Leake <stephen_leake@stephe-leake.org>
> Date: Wed, 05 Aug 2015 01:18:54 -0500
> 
> >> What's the use for "command that creates a manual" (even setting
> >> aside the fact that not all projects have that)?  Calling it in
> >> M-x project-create-manual, a command that only does that one
> >> thing?
> >
> > Yes, for starters.  Building the whole project from scratch, including
> > the manuals, is another.  Finding out whether the project _has_ a
> > manual building instructions is yet another.
> >
> >> Not very interesting, IMHO.
> >
> > I don't understand this criterion.  I think the criterion should be
> > "is this useful".
> 
> Apparently EDE has the notion of "targets" for this sort of thing. So
> the EDE users find it useful, for actually running the targets.
> 
> The question for project.el is whether is would be useful for _other_
> (non-EDE) elisp programs; we already have EDE to create and run the
> targets.

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).

> 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.  When you build
infrastructure, you don't wait for clients to come requesting basic
features.  You are supposed to study the use cases and the entities
you want to support, and provide support for at least the
standard/basic aspects and traits of those entities.  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.