Emacs freezes (~10s) with big node_modules directory when starting eglot #697

melias122 · 2021-05-26T13:33:38Z

Hey I am trying to move from lsp-mode to eglot but I have some issues one of the projects I currently work on. As title says when starting eglot in project containing node_modules (~50k files), emacs freezes for some time. When I remove
node_modules emacs does not freeze. Just to note, lsp-mode does not have this issue.

Server used: gopls
Emacs version: 28.0.50
Operating system: linux/ubuntu
Eglot version: a5b7b7d
Eglot installation method: use-package
Using Doom: no

LSP transcript - M-x eglot-events-buffer (mandatory unless Emacs inoperable)

[server-request] (id:2) Wed May 26 14:36:25 2021:
(:jsonrpc "2.0" :method "client/registerCapability" :params
	  (:registrations
	   [(:id "workspace/didChangeWatchedFiles-0" :method "workspace/didChangeWatchedFiles" :registerOptions
		 (:watchers
		  [(:globPattern "**/*.{go,mod,sum}" :kind 7)
		   (:globPattern "{/home/melias122/code/axonpro/mydoctor/cmd,/home/melias122/code/axonpro/mydoctor/cmd/import,/home/melias122/code/axonpro/mydoctor/cmd/jwtkeygen,/home/melias122/code/axonpro/mydoctor/cmd/mydoctor-frontend,/home/melias122/code/axonpro/mydoctor/cmd/mydoctord,/home/melias122/code/axonpro/mydoctor/config,/home/melias122/code/axonpro/mydoctor/db,/home/melias122/code/axonpro/mydoctor/db/minio,/home/melias122/code/axonpro/mydoctor/db/mysql,/home/melias122/code/axonpro/mydoctor/demo,/home/melias122/code/axonpro/mydoctor/hooks,/home/melias122/code/axonpro/mydoctor/http,/home/melias122/code/axonpro/mydoctor/imageutil,/home/melias122/code/axonpro/mydoctor/import,/home/melias122/code/axonpro/mydoctor/import/codebook,/home/melias122/code/axonpro/mydoctor/import/imports,/home/melias122/code/axonpro/mydoctor/import/xmlmodel,/home/melias122/code/axonpro/mydoctor/import/xmlmodel/dpxml,/home/melias122/code/axonpro/mydoctor/import/xmlmodel/liekxml,/home/melias122/code/axonpro/mydoctor/import/xmlmodel/ockovacikalendarxml,/home/melias122/code/axonpro/mydoctor/import/xmlmodel/zpxml,/home/melias122/code/axonpro/mydoctor/internal,/home/melias122/code/axonpro/mydoctor/internal/ambulanceserver,/home/melias122/code/axonpro/mydoctor/internal/authserver,/home/melias122/code/axonpro/mydoctor/internal/clinicserver,/home/melias122/code/axonpro/mydoctor/internal/codebookserver,/home/melias122/code/axonpro/mydoctor/internal/infoserver,/home/melias122/code/axonpro/mydoctor/internal/registrationserver,/home/melias122/code/axonpro/mydoctor/internal/userserver,/home/melias122/code/axonpro/mydoctor/jwt,/home/melias122/code/axonpro/mydoctor/log,/home/melias122/code/axonpro/mydoctor/mock,/home/melias122/code/axonpro/mydoctor/mocks,/home/melias122/code/axonpro/mydoctor/mydoctor,/home/melias122/code/axonpro/mydoctor/proto,/home/melias122/code/axonpro/mydoctor/pwhash,/home/melias122/code/axonpro/mydoctor/sms,/home/melias122/code/axonpro/mydoctor/third_party,/home/melias122/code/axonpro/mydoctor/valid,/home/melias122/code/axonpro/mydoctor/version,/home/melias122/code/axonpro/mydoctor/web}" :kind 7)]))])
	  :id 2)
[client-reply] (id:2) Wed May 26 14:36:33 2021:
(:jsonrpc "2.0" :id 2 :result nil)

The text was updated successfully, but these errors were encountered:

joaotavora · 2021-05-26T13:57:45Z

[ You skip some parts of the template that the template asks you not to skip. You are missing a minimal reproduction recipe. I need to be able to reproduce the error. Please, next time, don't skip the parts that say DO NOT SKIP. Alternatively, open a discussion]

Notheless I think this might be related to #645 or #633. Is this project publicly available somewhere?

danielpza · 2021-05-26T14:14:32Z

@melias122 do you have a tsconfig.json/jsconfig.json file? can you post it?

melias122 · 2021-05-26T14:22:13Z

@joaotavora, sorry for that. Repository is private, but I will try to make reproducible repo. I will also try v1.7 if it happens there.
@danielpza

jsonconfig.json
{
  "include": [
    "./src/**/*"
  ]
}

* eglot.el (eglot--directories-recursively): Fix.

joaotavora · 2021-05-26T14:32:32Z

@melias122 I wish you could also try the scratch/fix-697-attempt branch. Maybe try that before working on the reproducible repo.

I'd be very thankful if you can test this, since the issuers of the other issues didn't follow through.

melias122 · 2021-05-26T14:48:06Z

Just tried scratch/fix-697-attempt and it is working fine with no freezes. I would be nice if there is a way to specify directories to ignore. Or maybe just follow .gitignore.

joaotavora · 2021-05-26T14:49:24Z

Or maybe just follow .gitignore.

That's an idea...

jarreds · 2021-05-26T14:56:39Z

Or maybe just follow .gitignore.

lsp-mode has a customizable lsp-file-watch-ignored list variable for this. That works well, imo.

joaotavora · 2021-05-26T14:58:44Z

Yes, lsp has knobs for a lot of things, but asking the user to customize yet another knob in what should be an out-of-box experience is sub-optimal. So if following .gitignore works for the majority of cases, I welcome that simplicity.

jarreds · 2021-05-26T15:12:01Z

Simplicity is why I love eglot. As far as logic for specific version control systems, wonder if there is some inspiration (or code) to be found in Projectile VCS support.

joaotavora · 2021-05-26T16:20:04Z

Yes, Dmitry Gutov has suggested using project.el for this, so this is probably what I'll try soon.

…

On Wed, May 26, 2021, 16:12 Jarred Ward ***@***.***> wrote: Simplicity is why I love eglot. As far as logic for specific version control systems, wonder if there is some inspiration (or code) to be found in Projectile VCS support <https://docs.projectile.mx/projectile/2.3/projects.html#version-control-systems> . — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#697 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAC6PQYB75YYKOQRFUO5Q6LTPUFVRANCNFSM45SBZGLA> .

The directory-finding logic is probably a bit slower than using eglot--directories-recursively, but since it honours `.gitignores` and ignores more directories it's much faster overall. And guaranteed to create less watchers. Thanks to Dmitry Gutov <[email protected]> for the idea. * eglot.el (eglot--directories-recursively): Remove.

joaotavora · 2021-05-26T18:00:41Z

Pushed another commit making use of project.el for this. It's already a dependency of eglot.el anyway and is the rightful module to ask about ignored directories.

melias122 · 2021-05-26T20:19:49Z

Tried, now emacs pauses for ~2 seconds (which is not bad, but still there is pause), but on 835aa0e, there was no pause. My root .gitignore has:

**/node_modules

With empty .gitignore it is also ~2 seconds. Any clue why?

dgutov · 2021-05-26T20:37:48Z

Try evaluating these:

(benchmark 1 '(project-files (project-current)))

and

(benchmark 1 '(delete-dups (mapcar #'file-name-directory (project-files (project-current)))))

...and tell us the numbers.

joaotavora · 2021-05-26T20:37:57Z

Hmm, I used @dgutov 's suggestion which is faster in some cases but probably slower in others. For example in a full repo of the snowpack repository, it's faster by about 3x, but I guess in your example it's not worth it.

As I wrote:

The directory-finding logic is probably a bit slower than using
eglot--directories-recursively, but since it honours `.gitignores` and
ignores more directories it's much faster overall.  And guaranteed to
create less watchers.

I guess, I'll have to some a bit more work to try and get the best of both worlds.

joaotavora · 2021-05-26T20:41:08Z

@dgutov my theory if you have a directory with many many files, calling file-name-directory for each one is going to allocate a lot of strings. If project-files were to also return directories in the first place, both that allocation and the NlogN (at best) delete-dups would be avoided.

dgutov · 2021-05-26T20:41:14Z

It is slower than find, but I never compared against a Lisp-based directory enumerator. It's possible it is slower, of course, but even in gecko-dev (a huge project) the latter form prints "1.936423s" on my machine.

OTOH, it's possible that the list of directories returned by the new approach is longer, and you end up spending more time setting up watches.

joaotavora · 2021-05-26T20:41:48Z

OTOH, it's possible that the list of directories returned by the new approach is longer, and you end up spending more time setting up watches.

It's likely shorter, since it ignores more stuff. In the snowpack (https://www.snowpack.dev/) repo your approach was faster by about 3x than eglot--directories-recursively (which I have now deleted, but will bring back soon). That's because eglot--directories-recursively returns twice as many directories (and the excess directories were quite useless).

dgutov · 2021-05-26T20:44:56Z

calling file-name-directory for each one is going to allocate a lot of strings

It's definitely not the most optimal approach, but it shouldn't be too terrible for a one-time action on most small-to-moderate sized projects.

If project-files were to also return directories in the first place

We can add a new defgeneric, sure. Anyone is welcome to suggest an optimal implementation of it for a Git backend.

joaotavora · 2021-05-26T20:47:37Z

Following up to that, if @melias122 's .gitignore is only **/node_modules and nothing else, both approaches will return the same dirs, but the "make a big string with full dir name for each file then remove duplicates" approach is likely slower.

We can add a new defgeneric, sure. Anyone is welcome to suggest an optimal implementation of it for a Git backend.

I'm not sure about the need for defgeneric or what that means.

I just think that if eglot--directories-recursively could consult project.el's knowledge of what constitute "ignored" directories we would be golden. Maybe that is what project-ignores does?

If I manage that, I guess, eglot--directories-recursively could become project-directories.

joaotavora · 2021-05-26T20:59:28Z

@dgutov

project-ignores is a compiled Lisp function in `project.el'.

(project-ignores PROJECT DIR)

Return the list of glob patterns to ignore inside DIR.
Patterns can match both regular files and directories.

But how to match them? What datatype exactly is "glob" pattern, is it a regexp?

Oh I see they are actual glob strings, presumably of the find format. And I see project-files uses the find util and passes the globs down... Hmmm I wonder if this isn't going to be slow on windows/mingw...

My current thinking is to use eglot--directories-recursively, and compile the globs using Eglot's glob matcher (which is supposed to be fast) to do the filtering.

In the meantime, I'm reverting the last commit.

dgutov · 2021-05-26T21:10:17Z

but the "make a big string with full dir name for each file then remove duplicates" approach is likely slower

Don't forget about the extra overhead of several Lisp calls for every directory you are traversing. So I wouldn't be sure.

I'm not sure about the need for defgeneric or what that means.

A new generic function acting on project instances.

Oh I see they are actual glob strings, presumably of the find format.

Or of .gitignore format (with slight adjustment, as documented).

joaotavora · 2021-05-26T23:11:42Z

Don't forget about the extra overhead of several Lisp calls for every directory you are traversing. So I wouldn't be sure

I'm reasonably sure that's the case. The number of directories is dramatically smaller than the number of file. So if all other things equal, traversing directories is much faster.

The snowpack repo example was especially benevolent to your approach, likely because of the large .gitignores file.

However my ~/tmp directory more closely matches the case being described by @melias122

(defun eglot--directories-recursively (&optional dir)
  "Because `directory-files-recursively' isn't complete in 26.3."
  (cons (setq dir (expand-file-name (or dir default-directory)))
        (cl-loop with default-directory = dir
                 with completion-regexp-list = '("^[^.]")
                 for f in (file-name-all-completions "" dir)
                 if (file-directory-p f)
                 append (eglot--directories-recursively f))))

(defun eglot--directories-recursively-project (&optional dir)
  (delete-dups (mapcar #'file-name-directory
                       (project-files
                        (or (project-current nil dir)
                            (cons 'transient dir))))))


(cl-set-difference
  (eglot--directories-recursively-project "~/tmp/")
  (eglot--directories-recursively "~/tmp/")
  :test 'string=) ; nil

(length (eglot--directories-recursively "~/tmp/")); 678
(length (eglot--directories-recursively-project "~/tmp/")) ; 624 not sure why less...

(benchmark 10 '(eglot--directories-recursively-project "~/tmp/")) ; "Elapsed time: 3.594734s (0.419492s in 10 GCs)"
(benchmark 10 '(eglot--directories-recursively "~/tmp/")); "Elapsed time: 1.836761s (0.382498s in 9 GCs)"

Another way to go about this might be to simply go into project.el and make a version of project-files (called maybe project-directories) that puts type d instead of type f in the find call. If I hack that in, project-files starts returning the directories I want:

(length (project-files (cons 'transient "~/tmp"))); 678
(benchmark 10 '(project-files (cons 'transient "~/tmp"))); "Elapsed time: 2.580373s"

So even find -type d seems to be slower, though not as bad as current project-files. For my heterogenous ~/tmp dir, of course:

❯ find . -type f | wc -l
9932
❯ find . -type d | wc -l
678

joaotavora · 2021-05-27T00:11:33Z

Final thought on this:

Tried the Elisp glob approach, gave correct correct results but sucked in performance when comparing to find f. Guess find's C globs are much faster.
Many projects, not just the JS snowpack, seem to favour the find/project-files approach slightly.
However, since this particular performance problem happens only in a subset of LSP situations, I think I'm going to revert the last commit. No point in having this subpar version for the only person who still is bothered by the performance problem.
A project-directories addition to project.el is desired. Should be faster than the current project-files approach. Should actually be easy to implement.
@melias122 if you could post some statistics about the distribution of files names in your project (maybe even mangle the file names and keep the directory structure), it'd be nice.

dgutov · 2021-05-27T00:54:47Z

The more ignore entries there are, the slower the find implementation becomes (Git does some smart file tracking, or pattern precompilation, IDK, that makes this way faster). Likewise, a hand-written tree traversal written in Lisp will become slower with more ignore rules added, because it's fairly difficult to write something other than a loop with comparisons for each directory name against each glob to ignore.

However, since this particular performance problem happens only in a subset of LSP situations, I think I'm going to revert the last commit. No point in having this subpar version for the only person who still is bothered by the performance problem.

No objections from me, but that's why I asked @melias122 to run a couple of basic benchmarks. There might be something else going on.

A project-directories addition to project.el is desired. Should be faster than the current project-files approach. Should actually be easy to implement.

A find-based one? Like we have just demonstrated, I think, it can be faster in some projects, while slower in others.

dgutov · 2021-05-27T00:56:16Z

Also, when you were testing in ~/tmp, it wasn't a Git-backed directory, so you weren't taking advantage of git ls-files's performance boost.

melias122 · 2021-05-27T12:27:45Z

@dgutov I have **/node_modules in root .gitignore and also in adminapp/.gitignore there is node_modules.

joaotavora · 2021-05-27T13:20:15Z

I think the double star notation is not in all versions of Git. Maybe your shell is picking up one version and project.el is using another. Try just "node_modules". João

…

On Thu, May 27, 2021, 13:28 Martin Eliáš ***@***.***> wrote: @dgutov <https://github.com/dgutov> I have **/node_modules in root .gitignore and also in adminapp/.gitignore there is node_modules. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#697 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAC6PQ3N3HMFVDKWWYR5URTTPY3FFANCNFSM45SBZGLA> .

dgutov · 2021-05-27T13:30:25Z

I don't know, either seems sufficient to have the directory ignored in my local testing.

Even if just adminapp/.gitignore contains node_modules, (project-files (project-current)) does not return any files from within its contents. The only way this wouldn't work is if node_modules is checked into the repository.

melias122 · 2021-05-27T13:55:12Z

@joaotavora I tried both **/node_modules in root and node_modules in dirs where they are generated. None of theese works for me on master.

@dgutov why would we want to have node_modules in the repository? :-)

Looking in project.el it looks like only .gitignore at the root is supported

(cl-defmethod project-ignores ((project (head vc)) dir)
...
             ;; FIXME: This seems to be Git-specific.
             ;; And / in the entry (start or even the middle) means
             ;; the pattern is "rooted".  Or actually it is then
             ;; relative to its respective .gitignore (of which there
             ;; could be several), but we only support .gitignore at
             ;; the root.

dgutov · 2021-05-27T14:06:27Z

why would we want to have node_modules in the repository? :-)

That would be a mistake, yes, but it's the only case I know of where Git ignores its own .gitignore entries.

OTOH, you said that git ls-files behaves as expected, so this is probably not it.

Looking in project.el it looks like only .gitignore at the root is supported

That only affects what project-ignores returns, but the internal implementation of project-files for project-vc doesn't use it.

Could you maybe M-x edebug-defun on project--vc-list-files? And see whether it receives some unexpected arguments.

You can also try calling git ls-files -c -o --exclude-standard in the terminal.

melias122 · 2021-05-27T20:10:05Z

Hmm, I think I found whats wrong. I noticed different results for (length (delete-dups (mapcar #'file-name-directory (project-files (project-current))))) with and without projectile loaded 192 and 7658.

I have this in my config (in use-pacage projectile). I am not sure why this is causing troubles:

(defun m/projectile-project-find-function (dir)
  (let ((root (projectile-project-root dir)))
    (and root (cons 'transient root))))

(with-eval-after-load 'project
  (add-to-list 'project-find-functions 'm/projectile-project-find-function))

joaotavora · 2021-05-27T20:59:49Z

ah! nice. Kill that and we're good :-). Or maybe put it later in the list (what good is it anyway?).

dgutov · 2021-05-27T21:07:51Z

I am not sure why this is causing troubles:

It's a poor definition: you created a backend, based on Projectile's returned root, which has no ignores aside from the hardcoded standard ones. The file listing, instead of delegating to Projectile, just uses the default definition (based on find), which lists almost all files under the root. It is both slow and returns too many files.

And it also hijacks the symbol transient instead of using the backend-specific one, which probably made diagnosing this problem harder than it could have been.

If you really do use it for something, here's a better definition (EDITED):

(defun m/projectile-project-find-function (dir)
  (let ((root (projectile-project-root dir)))
    (and root (cons 'my/projectile root))))

(cl-defmethod project-root ((pr (head my/projectile)))
  (cdr pr))

(cl-defmethod project-files ((pr (head my/projectile)) &optional _dirs)
  (let ((root (cdr pr)))
    (mapcar
     (lambda (file)
       (concat root file))
     (projectile-project-files root))))

(cl-defmethod project-ignores ((pr (head my/projectile)) _dir)
  (let ((default-directory (cdr pr)))
    (projectile-patterns-to-ignore)))

(with-eval-after-load 'project
  (add-to-list 'project-find-functions 'm/projectile-project-find-function))

Feel free to ping Projectile's maintainer in bbatsov/projectile#1591, though.

melias122 · 2021-05-27T21:33:27Z

I took that from #129. @dgutov thanks, but I will just delete that and thank you both guys for helping me. 👍

…ory watching Previously, given a number of globs, Eglot would try to place system watchers only in those subdirectories that could potentially be matched by a glob. This meant traversing the whole tree, which could be impractical. Just place watchers in every subdirectory of the project (you may run out of watchers). * eglot.el (eglot-register-capability): Simplify. (eglot--files-recursively): Delete. (eglot--directories-recursively): Fix.

…n to "node_modules" directores * eglot.el (eglot--directories-recursively): Fix.

…atchers to skip The directory-finding logic is probably a bit slower than using eglot--directories-recursively, but since it honours `.gitignores` and ignores more directories it's much faster overall. And guaranteed to create less watchers. Thanks to Dmitry Gutov <[email protected]> for the idea. * eglot.el (eglot--directories-recursively): Remove.

…ory watching Previously, given a number of globs, Eglot would try to place system watchers only in those subdirectories that could potentially be matched by a glob. This meant traversing the whole tree, which could be impractical. Just place watchers in every subdirectory of the project (you may run out of watchers). * eglot.el (eglot-register-capability): Simplify. (eglot--files-recursively): Delete. (eglot--directories-recursively): Fix.

…n to "node_modules" directores * eglot.el (eglot--directories-recursively): Fix.

…atchers to skip The directory-finding logic is probably a bit slower than using eglot--directories-recursively, but since it honours `.gitignores` and ignores more directories it's much faster overall. And guaranteed to create less watchers. Thanks to Dmitry Gutov <[email protected]> for the idea. * eglot.el (eglot--directories-recursively): Remove.

Previously, given a number of globs, Eglot would try to place system watchers only in those subdirectories that could potentially be matched by a glob. This meant traversing the whole tree, which could be impractical. Just place watchers in every subdirectory of the project (you may run out of watchers). * eglot.el (eglot-register-capability): Simplify. (eglot--files-recursively): Delete. (eglot--directories-recursively): Fix. #697: joaotavora/eglot#697 #645: joaotavora/eglot#645

* eglot.el (eglot--directories-recursively): Fix. #697: joaotavora/eglot#697 #645: joaotavora/eglot#645

The directory-finding logic is probably a bit slower than using eglot--directories-recursively, but since it honours `.gitignores` and ignores more directories it's much faster overall. And guaranteed to create less watchers. Thanks to Dmitry Gutov <[email protected]> for the idea. * eglot.el (eglot--directories-recursively): Remove. #697: joaotavora/eglot#697

Previously, given a number of globs, Eglot would try to place system watchers only in those subdirectories that could potentially be matched by a glob. This meant traversing the whole tree, which could be impractical. Just place watchers in every subdirectory of the project (you may run out of watchers). * eglot.el (eglot-register-capability): Simplify. (eglot--files-recursively): Delete. (eglot--directories-recursively): Fix. GitHub-reference: fix joaotavora/eglot#697 GitHub-reference: fix joaotavora/eglot#645

* eglot.el (eglot--directories-recursively): Fix. GitHub-reference: per joaotavora/eglot#697 GitHub-reference: per joaotavora/eglot#645

The directory-finding logic is probably a bit slower than using eglot--directories-recursively, but since it honours `.gitignores` and ignores more directories it's much faster overall. And guaranteed to create less watchers. Thanks to Dmitry Gutov <[email protected]> for the idea. * eglot.el (eglot--directories-recursively): Remove. GitHub-reference: per joaotavora/eglot#697

gety9 · 2023-02-04T23:38:01Z

@joaotavora @dgutov

Joao and Dmitry hi,

Could you guys please tell:

1, is there a way to see what files are "monitored" by eglot/pyright? (i want to make sure that my settings are correct and only needed files are there (as few as possible for performance reasons))

2, for following project structure:

project root/
-------------/.git
-------------/pyrightconfig.json
-------------/scripts/ < all my python scripts here
-------------/data/
-------------/log/

What is the best way (for speed/perfromance) to tell eglot/pyright to "watch" only /scripts/ folder?

As i understand i can put it into pyrightconfig.json:

  "include": [
    "scripts"
  ],

or (judging from this thread) into .gitignore

*
!/scripts/

dgutov · 2023-02-05T13:24:50Z

That doesn't sound like a project management question, so I'll leave it to Joao.

joaotavora · 2023-02-05T13:44:03Z

Please post the contents of your Eglot events buffer. Or better yet find the message that asks Eglot to watch files, must be some "didChangeWatchedFiles" from server to client.

It's not clear what problem you are experiencing. Not all servers ask Eglot to watch files, and it's not clear how that impacts performance, assuming that's what you're worried about.

joaotavora · 2023-02-05T13:44:12Z

Please post the contents of your Eglot events buffer. Or better yet find the message that asks Eglot to watch files, must be some "didChangeWatchedFiles" from server to client.

It's not clear what problem you are experiencing. Not all servers ask Eglot to watch files, and it's not clear how that impacts performance, assuming that's what you're worried about.

joaotavora · 2023-02-05T13:45:41Z

Actually, the server to client message is of type "register Capability" with "didChangeWatchedFiles" being one of its arguments

gety9 · 2023-02-05T22:04:00Z

@joaotavora upon further checking i think problem is on my side i will try to troubleshoot it, and repost if i still have lagging/freezing issues. Thank you for quick replies.

melias122 changed the title ~~eglot+gopls freezes (~10s) with big node_modules directory when starting eglot~~ Emacs freezes (~10s) with big node_modules directory when starting eglot May 26, 2021

joaotavora added a commit that referenced this issue May 26, 2021

Per #697, #645: Hard code an exception to "node_modules" directores

835aa0e

* eglot.el (eglot--directories-recursively): Fix.

joaotavora closed this as completed in 25d20c7 May 26, 2021

joaotavora mentioned this issue May 27, 2021

Use with projectile #129

Closed

articuluxe mentioned this issue Jul 12, 2021

Now has hard dependency on projectile suonlight/multi-vterm#12

Closed

xor-xor mentioned this issue Jan 30, 2022

Eglot over TRAMP doesn't recognize "projects" properly #826

Closed

bhankas pushed a commit to bhankas/emacs that referenced this issue Sep 18, 2022

Per joaotavora/eglot#697, joaotavora/eglot#645: Hard code an exceptio…

67aaf5b

…n to "node_modules" directores * eglot.el (eglot--directories-recursively): Fix.

bhankas pushed a commit to bhankas/emacs that referenced this issue Sep 19, 2022

Per joaotavora/eglot#697, joaotavora/eglot#645: Hard code an exceptio…

ceff167

…n to "node_modules" directores * eglot.el (eglot--directories-recursively): Fix.

bhankas pushed a commit to bhankas/emacs that referenced this issue Sep 19, 2022

Per #697, #645: Hard code an exception to "node_modules" directores

72c4fc3

* eglot.el (eglot--directories-recursively): Fix. #697: joaotavora/eglot#697 #645: joaotavora/eglot#645

jollaitbot pushed a commit to sailfishos-mirror/emacs that referenced this issue Oct 12, 2022

Hard code an exception to "node_modules" directores

02dc703

* eglot.el (eglot--directories-recursively): Fix. GitHub-reference: per joaotavora/eglot#697 GitHub-reference: per joaotavora/eglot#645

Emacs freezes (~10s) with big node_modules directory when starting eglot #697

Emacs freezes (~10s) with big node_modules directory when starting eglot #697

Comments

melias122 commented May 26, 2021

LSP transcript - M-x eglot-events-buffer (mandatory unless Emacs inoperable)

joaotavora commented May 26, 2021

danielpza commented May 26, 2021

melias122 commented May 26, 2021

joaotavora commented May 26, 2021

melias122 commented May 26, 2021

joaotavora commented May 26, 2021

jarreds commented May 26, 2021 • edited Loading

joaotavora commented May 26, 2021

jarreds commented May 26, 2021

joaotavora commented May 26, 2021 via email

joaotavora commented May 26, 2021

melias122 commented May 26, 2021

dgutov commented May 26, 2021

joaotavora commented May 26, 2021 • edited Loading

joaotavora commented May 26, 2021

dgutov commented May 26, 2021

joaotavora commented May 26, 2021 • edited Loading

dgutov commented May 26, 2021

joaotavora commented May 26, 2021

joaotavora commented May 26, 2021

dgutov commented May 26, 2021

joaotavora commented May 26, 2021 • edited Loading

joaotavora commented May 27, 2021

dgutov commented May 27, 2021 • edited Loading

dgutov commented May 27, 2021

melias122 commented May 27, 2021

joaotavora commented May 27, 2021 via email

dgutov commented May 27, 2021

melias122 commented May 27, 2021

dgutov commented May 27, 2021

melias122 commented May 27, 2021

joaotavora commented May 27, 2021

dgutov commented May 27, 2021 • edited Loading

melias122 commented May 27, 2021 • edited Loading

gety9 commented Feb 4, 2023

dgutov commented Feb 5, 2023

joaotavora commented Feb 5, 2023

joaotavora commented Feb 5, 2023

joaotavora commented Feb 5, 2023

gety9 commented Feb 5, 2023

jarreds commented May 26, 2021 •

edited

Loading

joaotavora commented May 26, 2021 •

edited

Loading

joaotavora commented May 26, 2021 •

edited

Loading

joaotavora commented May 26, 2021 •

edited

Loading

dgutov commented May 27, 2021 •

edited

Loading

dgutov commented May 27, 2021 •

edited

Loading

melias122 commented May 27, 2021 •

edited

Loading