5

I have a situation where (project-current) gets the project root "wrong", i.e. not what I want it to be - specifically the project is part of a larger project that project.el doesn't know about. Is there any way to override that, using perhaps a dir-local variable or some other method?

GaryO
  • 476
  • 2
  • 16
  • Two questions: do you mean that the project root would be a subdirectory of a large Git (mono)repo? Or that you want the project to be larger than the current Git repo? – Dmitry Sep 27 '21 at 11:43
  • And if it's the former: would you want to "parent" project to still be able to include subproject's files as its own? And have project-find-file and project-find-regexp always search across subprojects? – Dmitry Sep 27 '21 at 11:44
  • What I meant by "specifically the project is part of a larger project" is that project.el thinks the project is rooted at /a/b/c/d (for whatever reason), but I want to override that so the project root is /a/b, which conceptually is my project root. So in my case there are no subprojects, just one big project to search. – GaryO Sep 28 '21 at 12:13
  • I'm asking about particular reasons the project root is detected where it is detected. To be able to choose the optimal technical implementation. – Dmitry Sep 28 '21 at 15:40
  • To be honest, at the time I wasn't super inclined to dig into the implementation to know why it was wrong. If I remember, my case was a Typescript/Vue app in a larger git monorepo, which might work fine now -- I guess I was hoping for a general "escape hatch" rather than a smarter root autodetection (though that's always great too!) – GaryO Sep 28 '21 at 21:20
  • I have a patch with a particular approach, and I was wondering whether it will work in your case: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41572#85. Sounds like it should work. – Dmitry Sep 28 '21 at 21:32
  • And the second question here in comments was to determine whether the premise for the approach taken in the patch has a good justification. – Dmitry Sep 28 '21 at 21:34
  • So if you could test the patch, it would be helpful. – Dmitry Sep 29 '21 at 11:28
  • I can't test it right now (will in a few weeks), but it looks like exactly what I was asking for. Thanks!! – GaryO Sep 29 '21 at 19:50
  • All right, and thanks in advance. It's unlikely to be accepted into Emacs 28 in a few weeks (the release window is closing), but we can distribute the updated version through GNU ELPA. – Dmitry Sep 29 '21 at 20:13

2 Answers2

3

I ran into this, too, and published the project-find-functions hook I use on https://michael.stapelberg.ch/posts/2021-04-02-emacs-project-override/:

;; Returns the parent directory containing a .project.el file, if any,
;; to override the standard project.el detection logic when needed.
(defun zkj-project-override (dir)
  (let ((override (locate-dominating-file dir ".project.el")))
    (if override
      (cons 'vc override)
      nil)))

(use-package project
  ;; Cannot use :hook because 'project-find-functions does not end in -hook
  ;; Cannot use :init (must use :config) because otherwise
  ;; project-find-functions is not yet initialized.
  :config
  (add-hook 'project-find-functions #'zkj-project-override))

Hope this helps :)

Michael
  • 156
  • 2
2

No buffer-local vars available as an option, but you can add your own element to project-find-functions which would call project-current in some parent directory.

Dmitry
  • 3,508
  • 15
  • 20
  • 2
    This is a crazy omission from a base project tool. it has taken me ages to find this. I think I'll need to move back to projectile. – RichieHH Jun 07 '21 at 10:43
  • @RichieHH Also see the questions I asked under the question. – Dmitry Sep 27 '21 at 11:54