bash-language-server: avoid recursive workspace scanning

[akurth]

Hello,

if I open an sh file in $HOME (say ~/.zshrc ), bash-language-server scans the entire directory for sh files recursively, which takes very long and uses a lot of CPU unnecessarily.

I guess it’s because workspaceFolders URI has been set to my home directory. Is there any way to set it to nil, or another way of disabling workspace scanning for this particular server?

Would appreciate any suggestions.

[nemethf]

One possible approach would be to create a project.el backend for which project-files doesn't traverse into sub-directories or returns files that the user explicitly defined as part of the project.

[joaotavora]

Sounds smart.

Another option, if I am right to assume you have your whole $HOME directory under Git version control, which project.el deals with by default is to use .gitignore or something so that project.el is informed of this.

Another option yet might be to use symbolic links. My ~/.zshrc points into something like ~/foo/library-of-sh-code/zee-shell-arrcee.zsh. I've yet to discover how M-x eglot with being invoked on symbolic links though. I don't think it'll send the referent directory to the server. But at least Emacs tells you that you're in a symlink and makes it easy to open the referent. Then you could M-x eglot there.

[akurth]

My home directory is not under version control. And my .zshrc is a plain file, since I’m using chezmoi to manage my config files.

I’m not sure whether project.el is involved here at all (isn’t ~ the default workspace root?), but I’ll have a look at the project backend suggestion.

[nemethf]

But I see what you mean: reading your descirption more closely, it is the LSP bash-language-server who is doing copious amounts of scanning

Isn't the server's behavior the result of Eglot's way of handling dynamic registration of workspace/didChangeWatchedFiles? I mean:

eglot/eglot.el

Lines 3063 to 3066 in d5e335f

	(dirs-to-watch
	(delete-dups (mapcar #'file-name-directory
	(project-files
	(eglot--project server))))))

---

I don't know what chezmoi is, but according to the docs, it seems to use a git repo under the hood in ~/.local/share/chezmoi.

[joaotavora]

Isn't the server's behavior the result of Eglot's way of handling dynamic registration of workspace/didChangeWatchedFiles? I mean:

That doesn't count as "scanning" for me, rather, "watching". And Eglot, the LSP client, only sets watchers when the server requests it to. But without more information, it's indeed unknown what is happening. I read:

bash-language-server scans the entire directory for sh files recursively,

.. as meaning that the LSP server is doing lots of scanning and that @akurth is looking for a (LSP) way to convince it to do less...

[akurth]

Please see the events log for ~/.zshrc here: https://nc.andreas-kurth.de/index.php/s/A6CW92TyxSzeZN7
(I deleted hundreds of similar "Analyzing file" lines and the contents of my .zshrc.)

If I open ~/bin/foo.sh, the first client request is:
(:jsonrpc "2.0" :id 1 :method "initialize" :params (:processId 17940 :rootPath "/home/ak/bin/" :rootUri "file:///home/ak/bin", and only the SH files within ~/bin are scanned.

[akurth]

This sounds related and seems to be what I’d like to have: muniter/neovim@ab86306

[joaotavora]

Yes. At least this confirms it's the LSP server doing the work. You might have some some luck turning off the verbose logging either on the server on on Eglot's side. See eglot-events-buffer-size. Though if it's "hundreds" of lines and not "thousands+", I don't think it'll make much of a difference.