Re: Subprojects in project.el (Was: Eglot, project.el, and python virtual environments)

[Dmitry Gutov]

On 02/12/2022 17:08, Dmitry Gutov wrote:
> project.el strives very hard to be generic, but what
> is the use in doing that if extending it by 3rd-party code is so
> complicated, and on top of that is not already available?

Speaking of "extending is complicated", I have shown the two-line 
definition of 'transient', right? A custom type can look just as short 
(or not; depending on its needs).

So it's more of a matter of understanding how the pieces fit.

For instance, using the new type will require plugging it into 
project-find-functions. And for the VC-aware type, its element is one of 
the more complex pieces of its implementation. Which makes sense: that's 
where domain complexity lies.

So how one would be able to reuse both it and the existing logic? Here's 
an example of overriding the 'project-name' with a new type without 
requiring a public constructor for the VC-aware type:

(defun project-try-my-type (dir)
  (let ((vc-instance (project-try-vc dir))))
  (cons 'my-type vc-instance))

(cl-defmethod project-root ((project (head my-type)))
  (project-root (cdr project)))

(cl-defmethod project-external-roots ((project (head my-type)))
  (project-external-roots (cdr project)))

(cl-defmethod project-files ((project (head my-type)) &optional dirs)
  (project-files (cdr project) dirs))

(cl-defmethod project-ignores ((project (head my-type)) dir)
  (project-ignores (cdr project) dir))

(cl-defmethod project-buffers ((project (head my-type)))
  (project-buffers (cdr project)))

(cl-defmethod project-name ((project (head my-type)))
  ;; Do something different here
  )

I suppose it does look a little verbose... A defclass or defstruct would 
allow to declare automatic inheritance between types. I wonder if there 
are any other options that don't imply structural inheritance, or if we 
can simply say "inheriting is fine, but please don't rely on the fields 
staying the same".