Re: IDE

[Dmitry Gutov]

On 10/21/2015 05:40 PM, Lluís wrote:

> Aha, I see we were imagining different ways of structuring the concepts. What I
> don't understand is what you mean with the parenthesis you add to some of the
> elements of your "service-type hooks". Are these dependencies between services?

Yes. And they're also function arguments. So the search-paths services 
would be implemented something like this:

(defun search-paths (project)
  (run-hook-with-args-until-success
   'search-path-functions
   project))

And let the others look like this:

(defun current-project (dir)
  (run-hook-with-args-until-success
   'project-find-functions
   dir))

(defun symbols-list (project search-paths)
  (run-hook-with-args-until-success
   'symbols-list-functions
   project
   search-paths))

Then a command which wants to use the symbols list will have to call all 
three of these functions.

> Now, how do you auto-detect what services to use on your currently open project?
> I.e., how do you auto-detect what service implementations must be used?

Each service implementation decides whether it's eligible, based on the 
PROJECT argument. It can ask the project for its root, or it can even 
check its struct/eieio/etc type, if it only want to work with certain 
kind of projects (for instance, when some project-find-functions and 
symbols-list-functions come from the same package, such as EDE).

> Maybe I wasn't explicit enough in my case, but project-types are the only ones
> that provide project detection, and therefore dictate the service
> implementations to use on your project.

Right. In this case, if I want to provide an search-paths implementation 
(maybe inside ruby-mode package), I also have to create a new project 
implementation, or look for an existing one to hook into somehow (that 
will most likely require some code modification).

Whereas, really, I can provide a rather small search-paths 
implementation that would fit the vast majority of Ruby projects, and 
would only look for Gemfile.lock in a parent directory, and depend on 
its contents (and maybe a few other file that signify the version of 
Ruby that's being used). That would nicely compose with Projectile as 
the project implementation, for instance.