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 18:23:06 +0300

> Cc: address@hidden, address@hidden, address@hidden
> From: Dmitry Gutov <address@hidden>
> Date: Wed, 5 Aug 2015 12:42:07 +0300
> 
>     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.
> 
> Project could define a way to build it whole, for instance, without giving 
> out specific information about every goal of build process.

It could, but why would it want to?  It sounds silly to have to
rebuild everything when you only need to rebuild some (small) part.

> Or exposing it all, in a standardized structure, without, however, having the 
> list of specific targets a project can support (manuals, etc) pre-defined.

Again, sounds silly, given how most, if not all, modern build tools
work.

But (shrug) not a catastrophe: the corresponding attribute will simply
be nil, or the command to build everything.

IOW, I see no problem here, and no reasons to consider this unfit for
the API.

>         Not very interesting, IMHO.
> 
>     I don't understand this criterion.  I think the criterion should be
>     "is this useful".
> 
> Just a criterion for what I spend time on.

I don't think you have this luxury when you work on infrastructure.

E.g., company.el is "not very interesting" for me, but I still try
very hard to fix every issue in the display engine that you or your
users report.

> Do you really consider this on the same of usefulness as, say, 
> xref-find-references?

Yes.  They are both no-brainers to have in the infrastructure that
AFAIU you are trying to provide.  It might even be much more useful to
a Lisp program that only cares about the manual of a project.



reply via email to

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