bug#73736: 31.0.50; project and therefore eglot don't work without git

bug#73736: 31.0.50; project and therefore eglot don't work without git

[Eric Gillespie]

(I don't use project directly, but eglot requires it, and that's
all I care about.)

1. cargo new foo
2. emacs -Q foo/src/main.rs
3. M-x rust-ts-mode RET
4. M-x eglot RET

Expected:
eglot activates.

Actual:
Error:
[eglot] Server reports (type=1): Failed to discover workspace.
Consider adding the `Cargo.toml` of the workspace to the [`linkedProjects`](https://rust-analyzer.github.io/manual.html#rust-analyzer.linkedProjects) setting.

I think the problem here is that eglot needs to provide a project
root to rust-analyzer, but 'project' only knows how to find .git
directories, which I don't have in this case.

This works in editors such as JetBrains Rover and VS Code
presumably because you have to take an "Open project" step in
those.  And I'd be OK if I had to that first in emacs, but I
could find no such option.

The closest I can find is 'project-switch-project', but it
doesn't accept arbitrary directories as input, instead only
allowing me to pick from a list it found on its own, by
scrounging around for .git directories!


In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, cairo version
 1.18.2) of 2024-10-04 built on dogato
Repository revision: ef587bf6b46b2ea3ef91b260ac2542666081260d
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101012
System Description: openSUSE Tumbleweed

Configured using:
 'configure -C --prefix=/opt/emacs-master --disable-silent-rules
 --with-x-toolkit=no --without-gsettings --with-native-compilation=no'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS HARFBUZZ JPEG LCMS2
LIBSELINUX LIBXML2 MODULES NOTIFY INOTIFY OLDXMENU PDUMPER PNG RSVG
SECCOMP SOUND SQLITE3 THREADS TIFF TREE_SITTER WEBP X11 XDBE XIM XINPUT2
XPM ZLIB

Important settings:
  value of $LC_CTYPE: en_US.UTF-8
  value of $XMODIFIERS: @im=local
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date subr-x mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils rmc iso-transl tooltip cconv eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/x-win x-win term/common-win x-dnd touch-screen tool-bar dnd fontset
image regexp-opt fringe tabulated-list replace newcomment text-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting font-render-setting cairo xinput2 x multi-tty
move-toolbar make-network-process emacs)

Memory information:
((conses 16 39589 10289) (symbols 48 5375 0) (strings 32 12072 1444)
 (string-bytes 1 289442) (vectors 16 9304)
 (vector-slots 8 103508 8407) (floats 8 25 4) (intervals 56 260 0)
 (buffers 992 10))

bug#73736: 31.0.50; project and therefore eglot don't work without git

[Dmitry Gutov]

Hi!

On 10/10/2024 19:44, Eric Gillespie wrote:
> I think the problem here is that eglot needs to provide a project
> root to rust-analyzer, but 'project' only knows how to find .git
> directories, which I don't have in this case.

This isn't very plug-and-play, but you can customize 
project-vc-extra-root-markers to include any other files that 
distinguish the root of a project. For example, Cargo.toml.

bug#73736: 31.0.50; project and therefore eglot don't work without git

[Jim Porter]

On 10/10/2024 11:42 AM, Dmitry Gutov wrote:
> This isn't very plug-and-play, but you can customize 
> project-vc-extra-root-markers to include any other files that 
> distinguish the root of a project. For example, Cargo.toml.

I wonder, could major modes provide project.el with some default values 
for that option? Then rust-mode could add Cargo.toml, python-mode could 
add pyproject.toml, and so on.

bug#73736: 31.0.50; project and therefore eglot don't work without git

[Dmitry Gutov]

On 10/10/2024 21:52, Jim Porter wrote:
> On 10/10/2024 11:42 AM, Dmitry Gutov wrote:
>> This isn't very plug-and-play, but you can customize project-vc-extra- 
>> root-markers to include any other files that distinguish the root of a 
>> project. For example, Cargo.toml.
> 
> I wonder, could major modes provide project.el with some default values 
> for that option? Then rust-mode could add Cargo.toml, python-mode could 
> add pyproject.toml, and so on.

That's a natural question, but it would result in different results for 
"current project" for files in the same directory (which often enough 
use different major modes).

What we could have, it a variable which is added to globally in package 
autoloads - so if e.g. rust-mode is installed it could add Cargo to root 
markers. For rust-ts-mode we'd need to do that in the core, but then 
we'd also need a way to override I guess, because in some projects that 
still wouldn't be "root"...

Speaking of JetBrains and VS Code's "Open project" method, we could have 
such as well - it would be a separate command or two ("open" and 
"close", maybe).

If it's just for Eglot, though, maybe ideally it would have a separate 
detector for directories in which to run the language server in - it 
doesn't have to correspond to what the user considers to be the entire 
project's root (they might prefer it to be a parent directory). Not sure 
how automatic it can be in the general case, though, and it'd require 
Eglot to know about root markers for all supported languages.

bug#73736: 31.0.50; project and therefore eglot don't work without git

[Joost Kremers]

On Fri, Oct 11 2024, Dmitry Gutov wrote:
> On 10/10/2024 21:52, Jim Porter wrote:
>> On 10/10/2024 11:42 AM, Dmitry Gutov wrote:
>>> This isn't very plug-and-play, but you can customize project-vc-extra-
>>> root-markers to include any other files that distinguish the root of a
>>> project. For example, Cargo.toml.
>> I wonder, could major modes provide project.el with some default values
>> for that option? Then rust-mode could add Cargo.toml, python-mode could
>> add pyproject.toml, and so on.
>
> That's a natural question, but it would result in different results for
> "current project" for files in the same directory (which often enough use
> different major modes).

What about a single marker that works for any project? This is a
work-around that Projectile uses and I'm using it with project.el as well,
with: 

```
(add-to-list 'project-vc-extra-root-markers ".project")
```

-- 
Joost Kremers
Life has its moments

bug#73736: 31.0.50; project and therefore eglot don't work without git

[Dmitry Gutov]

On 11/10/2024 11:53, Joost Kremers wrote:
>> That's a natural question, but it would result in different results for
>> "current project" for files in the same directory (which often enough use
>> different major modes).
> What about a single marker that works for any project? This is a
> work-around that Projectile uses and I'm using it with project.el as well,
> with:
> 
> ```
> (add-to-list 'project-vc-extra-root-markers ".project")
> ```

That's the recommended course of action if you don't have other 
consistent indicators of project root, between your projects.

I'm not a fan of adding a file that has no other purposes, but if people 
find this useful, no problem. For personal projects it certainly 
shouldn't hurt.

Eric, Jim, how would you like this resolution?

bug#73736: 31.0.50; project and therefore eglot don't work without git

[Ship Mints]

[-- Attachment #1: Type: text/plain, Size: 1068 bytes --]

I assume you're not suggesting adding ".project" to everyone's Emacs
default configurations. It's a user option already (which I do use).

On Fri, Oct 11, 2024 at 1:14 PM Dmitry Gutov <dmitry@gutov.dev> wrote:

> On 11/10/2024 11:53, Joost Kremers wrote:
> >> That's a natural question, but it would result in different results for
> >> "current project" for files in the same directory (which often enough
> use
> >> different major modes).
> > What about a single marker that works for any project? This is a
> > work-around that Projectile uses and I'm using it with project.el as
> well,
> > with:
> >
> > ```
> > (add-to-list 'project-vc-extra-root-markers ".project")
> > ```
>
> That's the recommended course of action if you don't have other
> consistent indicators of project root, between your projects.
>
> I'm not a fan of adding a file that has no other purposes, but if people
> find this useful, no problem. For personal projects it certainly
> shouldn't hurt.
>
> Eric, Jim, how would you like this resolution?
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 1558 bytes --]

bug#73736: 31.0.50; project and therefore eglot don't work without git

[Dmitry Gutov]

[-- Attachment #1: Type: text/plain, Size: 241 bytes --]

On Fri, Oct 11, 2024, at 7:40 PM, Ship Mints wrote:
> I assume you're not suggesting adding ".project" to everyone's Emacs default configurations. It's a user option already (which I do use).
I am - if it helps avoid this recurring question.

[-- Attachment #2: Type: text/html, Size: 545 bytes --]

bug#73736: 31.0.50; project and therefore eglot don't work without git

[Ship Mints]

[-- Attachment #1: Type: text/plain, Size: 565 bytes --]

If you're really serious about this, I'd like to suggest ".project.el" or
"project.el" over an unadorned ".project" to avoid clashing with
third-party software that uses .project files or directories for its own
purposes.

On Fri, Oct 11, 2024 at 5:20 PM Dmitry Gutov <dmitry@gutov.dev> wrote:

> On Fri, Oct 11, 2024, at 7:40 PM, Ship Mints wrote:
>
> I assume you're not suggesting adding ".project" to everyone's Emacs
> default configurations. It's a user option already (which I do use).
>
> I am - if it helps avoid this recurring question.
>

[-- Attachment #2: Type: text/html, Size: 1153 bytes --]

bug#73736: 31.0.50; project and therefore eglot don't work without git

[Dmitry Gutov]

On 12/10/2024 17:32, Ship Mints wrote:
> If you're really serious about this, I'd like to suggest ".project.el" 
> or "project.el" over an unadorned ".project" to avoid clashing with 
> third-party software that uses .project files or directories for its own 
> purposes.

It's probably not going to be an Elisp file (with some code inside).

And it's been mentioned in this thread that some other software uses 
file with this name in the project root. If there is data indicating 
that such dirs should not be recognized as project root in many other 
cases, we should of course reconsider. But from what I've seen in 
threads on Reddit and relater articles, people like this particular file 
name for this purpose.

bug#73736: 31.0.50; project and therefore eglot don't work without git

[Ship Mints]

[-- Attachment #1: Type: text/plain, Size: 1280 bytes --]

Yeah, people can just override the default but I wonder how many people
will be surprised. I've been experimenting with .project.el files that
indicate common project contents that span different directory hierarchies,
basically a .project.el that sets a ("safe") variable so I can try to get
tooling to look across file systems rather than just assume one base. Still
working through that to gauge its utility vs. support tooling complexity.

On Sat, Oct 12, 2024 at 4:30 PM Dmitry Gutov <dmitry@gutov.dev> wrote:

> On 12/10/2024 17:32, Ship Mints wrote:
> > If you're really serious about this, I'd like to suggest ".project.el"
> > or "project.el" over an unadorned ".project" to avoid clashing with
> > third-party software that uses .project files or directories for its own
> > purposes.
>
> It's probably not going to be an Elisp file (with some code inside).
>
> And it's been mentioned in this thread that some other software uses
> file with this name in the project root. If there is data indicating
> that such dirs should not be recognized as project root in many other
> cases, we should of course reconsider. But from what I've seen in
> threads on Reddit and relater articles, people like this particular file
> name for this purpose.
>

[-- Attachment #2: Type: text/html, Size: 1721 bytes --]

bug#73736: 31.0.50; project and therefore eglot don't work without git

[Jim Porter]

On 10/10/2024 2:59 PM, Dmitry Gutov wrote:
> If it's just for Eglot, though, maybe ideally it would have a separate 
> detector for directories in which to run the language server in - it 
> doesn't have to correspond to what the user considers to be the entire 
> project's root (they might prefer it to be a parent directory). Not sure 
> how automatic it can be in the general case, though, and it'd require 
> Eglot to know about root markers for all supported languages.

Yeah, that raises a good point: what exactly counts as a "project" 
depends on the context. For simple scenarios, a project is approximately 
equal to a VC repository, but for more complex scenarios, I think it 
depends on what you want to *do* with the project. For example, suppose 
I have a Git monorepo that has several different Python packages in it. 
Should Emacs consider the monorepo to be the lone project, or should 
each Python package be a project? I don't know if either answer is 
correct 100% of the time.

(Even if we're just thinking about VC, "what project is this file in?" 
can have multiple answers. Sometimes if I'm working in a Git submodule, 
I want that submodule to be the project, not the parent repo.)

I'm not sure if we should open this can of worms yet though...

> I'm not a fan of adding a file that has no other purposes, but if people find this useful, no problem. For personal projects it certainly shouldn't hurt.
> 
> Eric, Jim, how would you like this resolution? 

I'm fine with recognizing ".project" by default, since it seems we'd 
just be adopting an already-existing practice. In addition to the cases 
already discussed, it seems that the Eclipse and STM32 IDEs also use a 
".project" file at the project root for various things.

To turn it around though, are there cases we know of where we *wouldn't* 
want ".project" to mark a project root? Maybe if an Eclipse IDE project 
were in a Git subdir? (In that case, maybe ".project" should only be 
checked for as a fallback if we couldn't determine the project using a 
"real" VC file.)

bug#73736: 31.0.50; project and therefore eglot don't work without git

[Dmitry Gutov]

On 12/10/2024 00:49, Jim Porter wrote:
>> I'm not a fan of adding a file that has no other purposes, but if 
>> people find this useful, no problem. For personal projects it 
>> certainly shouldn't hurt.
>>
>> Eric, Jim, how would you like this resolution? 
> 
> I'm fine with recognizing ".project" by default, since it seems we'd 
> just be adopting an already-existing practice. In addition to the cases 
> already discussed, it seems that the Eclipse and STM32 IDEs also use a 
> ".project" file at the project root for various things.

That's good to know.

> To turn it around though, are there cases we know of where we *wouldn't* 
> want ".project" to mark a project root? Maybe if an Eclipse IDE project 
> were in a Git subdir? (In that case, maybe ".project" should only be 
> checked for as a fallback if we couldn't determine the project using a 
> "real" VC file.)

That would require a new variable because 
project-vc-extra-root-markers's original goal was to allow sub-projects 
inside a VC repo (or projects outside of any repos).

At this point I'd rather recommend users who prefer a different behavior 
to customize this var to a different value, removing .project from it.