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:16:22 +0300

> Cc: address@hidden, address@hidden, address@hidden
> From: Dmitry Gutov <address@hidden>
> Date: Wed, 5 Aug 2015 18:31:35 +0300
> 
> On 08/05/2015 06:23 PM, Eli Zaretskii wrote:
> 
> > Again, sounds silly, given how most, if not all, modern build tools
> > work.
> 
> That is counter to my experience. The modern build tools work in a 
> variety of different ways.

You mean, some of them don't support specifying how to build
documentation?  Which ones?

> > But (shrug) not a catastrophe: the corresponding attribute will simply
> > be nil, or the command to build everything.
> 
> And I don't understand what you mean here.

An attribute can exist even if with some projects its value will be
nil or a trivial "build-all" command.  IOW, even if some projects
won't have any non-trivial value for this attribute, it's not an
argument against the attribute's existence.

> > IOW, I see no problem here, and no reasons to consider this unfit for
> > the API.
> 
> It's fit. As soon as we're sure someone is going to write a Lisp program 
> making use of this part of the API. And by "sure", I mean we have at 
> least a proof-of-concept patch for a non-trivial piece of functionality.

I don't think it's correct to wait for specific requests for every
single sub-feature, when developing infrastructure like this one.
Some basic traits should be supported just because they are basic,
before someone asks.

> > I don't think you have this luxury when you work on infrastructure.
> 
> I don't think anyone here has the authority to tell me what to spend 
> time on.

I didn't tell you anything except my views on this.

> > 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.
> 
> You don't work on adding new features to it, however.

Yes, I do.  But that's besides the point, isn't it?

> > 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.
> 
> It makes sense to go for features with bigger impact first.

If this is just a matter of priority, I'm okay with whatever the
decision is.  I was under the impression that the mere need is being
questioned.



reply via email to

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