Re: IDE

[Dmitry Gutov]

On 10/18/2015 09:21 PM, Lluís wrote:

> No, I mean something as simple as concatenating the project's root with a
> non-absolute path given as an argument. Search or include paths are specific to
> the organization of the project at hand (e.g., on a C project not every
> directory should be searched for an include), but could be implemented on top of
> the "find path" functionality.

Then, UUIC, maybe that would be called "find relative path". Similar to 
https://atom.io/docs/api/v1.0.19/Project#instance-relativizePath

> That's one of my concerns with the project concept. As you pointed out,
> behaviour can change, for example, based on the mode of the file you're working
> on. This can be the case for projects that contain code in multiple languages,
> so that each can be treated slightly differently.

We can't rely on the current file being the deciding factor, however. At 
least some users would expect that if we're in a given project (say, in 
an open Dired buffer, or in a YAML config, or in a Compilation buffer), 
and the project contains Ruby files, the search for references to `each' 
would still use the Ruby search path.

> The question is thus, for example, how do we fit the major-mode variable into
> this scheme? The problem becomes multi-dimensional, and I'm not sure how to
> specify that. Should some service-types be dependant on the major-mode, such
> that a project can have mutiple services for the same type but for different
> major-modes?

The language can be passed as a second argument to 
project-search-path-functions elements. But then the project would need 
to know the set of languages to pass in.

As long as we prohibit search-path from depending on the current buffer, 
any parameters need to passed in explicitly (except one, see below).

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

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

> 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?

> Note that some other project-type might provide a more intelligent S2 that, for
> example, takes information from a compilation database.

Right.

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

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

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