Re: IDE

[Dmitry Gutov]

On 10/19/2015 04:04 PM, Lluís wrote:

> That's the point I wanted to raise. How flexible should the underlying
> infrastructure be? And based on what should it be flexible?

Well, yeah. These are the practical questions, decisions on which will 
shape the result.

Having limitations isn't bad, as long as the user will still be able to 
enjoy useful behavior, one way or another.

Option one: we allow search-path to depend on default-directory (in 
addition to the current project). Then the user can employ VC as a 
backend for projects, and yet have several different applications inside 
that repository. I'm describing this on the basis of one of the projects 
we have at work.

Option two: we disallow search-path depending on default-directory. 
Then, for the same project, VC can't be the backend, and the "project" 
will have to be split into several (VC can't be used as a backend 
heere). Which will make at least as much sense. It will require a 
special project type for Ruby, based on the presence of Gemfile.

> I think I did not explain myself well. I meant having one hook variable for each
> public method of each service type.

Why aggregate them into service types, then? Just call each "public 
method" (or hook) a separate service.

> If every project-type T* has a probing function that tells you if it's
> applicable to your current project, then you simply overlay all project types
> that match (or support) your project.
>
> IMHO, how to expose this to the user is a question that needs answering later

The "overlaying" process would also need some explanation. And 
consideration.

Suppose there are several implementations of the same service-type, and 
the results they return (like search-path elements) overlap. How would 
you produce the resulting list? (delete-dups (apply #'append ...))?

That would assume that there can't be "bad" (less precise) elements. For 
the "find references" service (if we had one), you would want to only 
keep the precise results, if available, a not mash them together with 
the output of Grep.

> Ok, so the first time you call `project-current', the system can check all
> project-types it knows about and see which ones apply to your file. From that a
> project object object is created overlaying the matched project-types. Next time
> you request `project-current' a cached value can be returned, or maybe looking
> at the value of some parent directory.

Caching is incidental. And I still don't know what "overlaying" is. In 
solid details, I mean.

> Ok, so it seems that we have two kinds of operations:
>
> * global: an operation that behaves the same regardless of where you're
>    performing the request from
>
> * local: an operation that can behave differently depending on the path you're
>    performing the request from, depending on the major-mode, depending on some
>    environment variable, or depending on some other arbitrary condition
>
> Would it ever make sense for a service method to provide both kinds of
> operations? (i.e., discriminate through an argument)

It might. The "find included file" operation would probably want to 
consider the type of the current file.

The environment variable can be looked up from the service itself. 
Arbitrary conditions are fine, as long they're not dependent on the 
current buffer too much.

> That's true, the user always needs some "backdoor" to customize behavior, since
> there's no global behavior that can fit all cases.

The user would always be able to rearrange the elements in a hook, or 
add their own function (service implementation), maybe composing 
existing ones.