Re: IDE

[Lluís]

Dmitry Gutov writes:

> On 10/18/2015 09:21 PM, Lluís wrote:
[...]
>> If that sounds reasonable, then why not also account for the path of the 
>> current
>> file? The same project might have different file search paths for different
>> files...

> Yes. Add the "directory" parameter (or pass it implicitly by binding
> `default-directory')? The list is getting longer...

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


>> I was thinking of service-types as providing multiple methods (hook 
>> variables),
>> one per function it exposes.

> Nothing can contain multiple hook variables. Hook variables are global. The
> values returned from them, however, could define several methods.

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


>> Now, there can be some best-effort project-type T0 that provides a 
>> brain-dead S2
>> that looks at all sub-directories. If you create your project overlaying T0 
>> and
>> T1, you can always get some best-effort functionality in case you're not 
>> using
>> any well-known project type.

> At which point does a project become "overlaying" T0 and T1? Would that be a
> tricky configuration a user would have to perform in a file inside the root
> directory of each of their projects?

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


[...]
>>> How would a random command that needs certain info from services x, y and 
>>> z, use
>>> this API?
>> 
>> Does the previous paragraph answer it now?

> Not really. I "create" a project? Could you rephrase that in terms of the
> project.el API?

> Here's an example: the command calls `project-current', which returns the
> current detected value of project. Then it passes it to
> `project-current-search-path', which consults project-search-path-functions 
> and
> returns an object describing the search-path, which the command uses with
> another method.

> Something will "create" a project (the user, somehow, or a minor mode), but
> that's of no interest to the API.

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.


>> What troubles me the most is nesting,
>> where each sub-directory might need to behave differently (e.g., have files 
>> for
>> different programming languages).

> I worry more about directories with files for different programming languages
> all inside them. At some point, some code will either have to prompt the user,
> guess somehow, or ask for search-path for all the languages, and then combine
> the results.

>> Would then each file or directory have a
>> potentially different project instance? Or should the project abstraction
>> account for different services on different paths?

> Maybe we should decide that search-path must be the same for all directories
> inside a project. Otherwise, we'd get different results for commands called 
> from
> different directories, sometimes with no apparent reason.

> Still unsure about it.

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)


>>> The one that comes first in the hook. Hook entries from minor modes usually 
>>> come
>>> before the hook entries from major modes, and it's user's responsibility 
>>> not to
>>> enable several minor modes at once that share the same responsibility.
>> 
>> I'd prefer the system to be able to auto-detect the proper type whenever
>> possible, instead of relying on the user establishing order for each possible
>> directory.

> How would having numeric priorities help? They'd still be static and apply to
> all directories.

> Also note that for project types supplied for Emacs, we'd be able to put them
> into hooks in the proper order. With third-party code, however, the order 
> might
> be wrong sometimes, but we also have no guarantee that their authors would
> assign correct priorities.

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


Cheers,
  Lluis

-- 
"And it's much the same thing with knowledge, for whenever you learn
something new, the whole world becomes that much richer."
-- The Princess of Pure Reason, as told by Norton Juster in The Phantom
Tollbooth