Use a different directory than project's root

[DamienCassou]

I have a git repository with a C# web server and a JS web client in 2 separate sub-directories. The LSP servers must be started on the sub-directories and not on the git project's root.

Is there a way to specify another directory than the project's root?

[joaotavora]

You can use project.el's facilities to designate a different directory as the root of a project in your file system. Searching for git is only a default, as far as I know. Look into project.el's documentation.

[dgutov]

In the end, it's a question of UX. Would the user in this situation expect M-x project-find-file to be limited to the contents of the web directory? Probably not (though there must exist monorepos where they would). The project.el data structures should try to follow what the user "feels" constitutes their project.

Whereas for LSP protocol there are certain technical conditions to choose the "project root", and in the end it uses it in a different sense. So at some point you will implement some special root-finding logic, and then using project.el will become untenable.

I can understand trying to piggy-back from existing solution, though (which expresses existing user configurations). Maybe you can add eglot-root-functions, the elements of which take the "current project" (from project-current), if any, as an argument. Or maybe you can add a dir-local var eglot-project-subroots which the users will set to a list of relative directory names such as '("Backend/Web" "public").

[joaotavora]

I don't understand the problem well enough to understand how your proposal or
even my proposal solves anything. I just have a feeling that there are ample opportunities to solve things well within the bounds of project.el and eglot.el 's philosophies.

[DamienCassou]

You can use project.el's facilities to designate a different directory as the root of a project in your file system.

I guess you are referring to project-find-functions. Adding a function here dedicated to detecting my project's boundaries seems like a good idea. Thanks.

Do the server and the client perhaps reside in separate submodules?

No. I guess I could have used a dir-local value for project-vc-merge-submodules otherwise.

I agree with @dgutov that using project.el's notion of root may be too limiting to decide the root for LSP. There is no reason for both to be the same directory.

[joaotavora]

I agree with @dgutov that using project.el's notion of root may be too limiting to decide the root for LSP.

It's pretty clear that it's default notion of root is limiting: it's a heuristic that happens to work well in a large number of cases, but not all. You have to inform project.el about your LSP needs, so that eglot.el can take advantage.

That said, In my experience own with LSP, servers will serve a project with subdirectories fine, so say you have a python client and a go server in the same repo, you could likely just do nothing and things would work, since LSP servers are "keyed" by project+major-mode.

But your servers may indeed want to be something else. You have to first decide how you would like to mark/configure your LSP roots inside your multi-LSP git repository. A specially named file? A hardcoded line in your .emacs? Something else?

Once that is done, we can figure out an element for project-find-functions so that project.el's project-finder:

1. returns the correct LSP root when invoked within a certain LSPian context, like M-x eglot and others
2. returns the .git project when doing other non-LSPian things, say like grepping a project or finding a file.

To have that function be able to tell if it's within an LSP context, it's likely that a bit of context has to be passed by eglot.el. That's fine. And then you have to decide how the function should discover the LSP root (and that's up to you, though if you pick a particularly good and generalizable strategy we can also put it in eglot.el for convenience).

[DamienCassou]

Very good summary. I will start by customizing project.el for my project regardless of LSP. Then, if I realize I would rather have 2 separate notions of project I will come back.

[joaotavora]

@DamienCassou see #689 for the infrastructure that could help you solve your problem by adding a given function to project-find-functions.

[xmatos-so]

I solved this issue using project-vc-extra-root-markers.

[dgutov]

Or is it something.git?

[gety9]

@dgutov Just .git, and it's not file - it's directory, where all regular git contents are (like HEAD, objects, refs, etc) - it was created with magit.

[dgutov]

Ah, okay. So it's not a misdetection of a Git repository. Just an unusual project structure.

In that case the above recommendation sounds good: you create your own wrapper for project-try-vc. Or just a replacement.

One alternative would be for you to delete Git from vc-handled-backends. But that would also make the VC features in Emacs unusable for those files. And I'm not sure if you want to ignore the .git dir as a project marker globally, or just this particular one.

Another alternative would be to add custom predicates to customized markers in project-vc. I've been thinking about it, but there's no code yet. It might work like adding (cons ".git" (lambda (file) (not (equal (file-name-directory) ".../scripts"))) to project-vc-extra-root-markers, or it would be a separate var, etc. You can file a feature request with M-x report-emacs-bug and track it there.

[gety9]

@dgutov Dmitry, sorry to trouble you again, could you tell what are the ways to make project.el disregard .gitignore files?

I have project were i ignore files with .gitignore for version control purporses, but still need them to be accesible in emacs (for coding, editing, etc). Basically i want project.el to behave like this .gitignore does not exist.

I replaced project-try-vc in project-find-functions� list with my own function assuming that's all i need to do (to use .myprojectmarker instead of .git), but no. Seems like project-find-functions� is used to find roots, but gitignore part is handled by different function.

[dgutov]

@gety9 When your backend is used, its definition of project-ignores and project-files are what determines whether any .gitignore rules are used. So if .gitignore is still honored, I would check that your backend is actually being used. What does your function return?

For anybody else reading this, I want to add that for the "VC-aware" project backend there is no such option at the moment. But if you need to visit such files ("ignored" ones) rarely enough, you can use the prefix argument with project-find-file: C-u C-x p f will list all the files under the project root (aside from those in directories matching the entries in vc-directory-exclusion-list, but those are a much smaller set).

But if you set up a different backend, .gitignore is definitely not used automatically. The default implementation of project-ignores only looks up the variables vc-directory-exclusion-list and grep-find-ignored-files.

[dmvianna]

Here's a way:

(use-package inheritenv
  :straight (inheritenv :type git :host github :repo "purcell/inheritenv"))

(use-package envrc
  :straight (envrc :type git :host github :repo "purcell/envrc")
  :commands (envrc-mode)
  :hook ((scala-mode . envrc-mode)))

(use-package project
 :init
 (setq project-vc-extra-root-markers '(".envrc")))

I have set it up for Scala and .envrc, but you could set it for any mode and filename. inheritenv and envrc are only relevant if you use direnv. The relevant bit is setting the project-vc-extra-root-markers variable after you updated it to the latest version (later than the one that ships with emacs 28.2).