search

non-Jedi / eglot-jl

Wrapper for using Julia LanguageServer.jl with emacs eglot
Creative Commons Zero v1.0 Universal
62 stars 11 forks source link

eglot-jl-init makes project-find-regexp disrespect .gitignore #42

Open rntz opened 1 year ago

rntz commented 1 year ago

emacs 28.2 eglot-jl 2.2.1 eglot 1.15

I have a large julia project which is also a git repository and contains large (~1GB) downloaded text data files. These are gitignored. Before using eglot-jl, project-find-regexp would not search these files. After running eglot-jl-init, it does search them, making project-find-regexp badly laggy (several seconds). Worse, it's uninterruptible (stuck in call-process-region) for most of this time.

I think this is because eglot-jl-init runs (add-hook 'project-find-functions #'eglot-jl--project-try). This causes (project-current) to return (julia . ROOTPATH), and you've only defined the project-root method for julia projects, so other methods fall back to the defaults. In this case, I think the relevant method is project-files?

Previously (project-current) would return (projectile . PATH) or (vc Git PATH), and it appears these have implementations of project-files which ignore things listed in .gitignore.

I'm honestly not sure what the right approach to fixing this is. For my purposes it would work to just not install the eglot-jl--project-try hook, but I can see why it can be useful. You could of course override project-files to respect .gitignore, but it would be nice to somehow re-use that functionality from the other project implementations.

rntz commented 1 year ago

(There's also the issue of why project-find-regexp hangs uninterruptibly while doing the search, instead of doing something asynchronous, but that's outside of your control :P. But even if it were asynchronous, it would still be very slow for me.)

non-Jedi commented 2 months ago

I've been kind of thinking about this in the background of my mind for a while, and I don't have any solution I'm super happy with.

The options look something like:

  1. Leave it as-is, and people using features of other project.el backends lose access to those features and run into dumb confusing issues like you've documented above.
  2. Don't add eglot-jl--project-try to project-find-functions, and document that this extension only works in Julia projects where a VC directory directly corresponds to the Julia project. We can leave eglot-jl--project-try as something the user has to explicitly opt in to.
  3. Re-implement or hook into all the features of the VC project backend (Not gonna do this because I think the code to do so would dwarf everything else in this minimal package).
  4. Would depending on projectile instead of directly on project.el get us this kind of thing for free? Not familiar with projectile, so I can't say.

I think I'm leaning toward choosing number 2 instead of 1. That appears to be the default for other language-specific project structures.

EDIT: Or maybe there's an option 5, and I just didn't read far enough in the linked thread...