didChangeWatchedFiles does not work recursively, LSP server goes out of sync for new directories #1414
Replies: 4 comments 5 replies
-
Showing fs events to the user is not Eglot's core business. It's an implementation detail that some servers need to do certain things. Can you explain what the problem to the user really is, from a non-Elisp perspective? Also, where is the event log for the short experiment? |
Beta Was this translation helpful? Give feedback.
-
|
The problem to the user is that LSP functionality like Specifically, after adding the When Here is the EGLOT buffer log for the steps to reproduce provided above: I hope this makes more sense now, let me know if you need additional details. |
Beta Was this translation helpful? Give feedback.
-
Hmmm, no. I'm more confused now :-) What has organize imports have to do with creating directories? Is creating these directories and files within these directories a part of what the server does when being asked to organize imports? if so, why does it need to be notified about the files it itself is creating? |
Beta Was this translation helpful? Give feedback.
-
|
In Go, each Go package has its own directory. See https://go.dev/doc/modules/layout for more details. After creating a new directory with .go files in it (= creating a Go package), I expect the organize imports feature to find said package. The server doesn’t create anything — I, the user, am creating files and directories, but the server doesn’t pick them up. See also my other reply to your other question regarding a reproduction recipe. |
Beta Was this translation helpful? Give feedback.
-
|
Can you give me a recipe that doesn't require me to add Elisp advice to things and where I as a Go newbie that just has Emacs with Eglot would see the unexpected erroring behavior? Start from some kind of hello world example and describe the steps I should take, like type this here, click there, etc, please. |
Beta Was this translation helpful? Give feedback.
-
|
Sure: Create a minimal Go project like so: mkdir hello2
cd hello2
go mod init hello2
cat > hello2.go <<'EOT'
package main
import (
"fmt"
)
func main() {
fmt.Printf("hey, what’s up?")
}
EOT
mkdir -p internal/foo
cat > internal/foo/foo.go <<'EOT'
package foo
var Bar = "yo"
EOT
package bar
var Baz = "sup"
When restarting Emacs (or just M-x eglot) and running M-x eglot-code-action-organize-imports again, the import is added as expected. |
Beta Was this translation helpful? Give feedback.
-
|
OK, I think I follow. So the problem is the Regardless, shouldn't there be a I think I understand what you request, but am skeptical of complicating Eglot to do what you request because:
|
Beta Was this translation helpful? Give feedback.
-
Yes, Emacs asked me whether it should create the directory and I said yes.
Yeah, once I
Users generally don’t expect that they have to restart parts of their editor setup after certain operations. To me, this sounds like a bug, not something I should be expected to remember.
See golang/go#67529 (comment) for details. The summary is that support on macOS seems worse than Linux.
Opening files is only one way to run into this situation. Another way is to use the go tool to import packages that are not yet stored on disk. See golang/go#62330 for such an issue (on macOS). In general, I would expect being able to modify my project outside of Emacs and have Emacs gracefully react to these changes. That has been the situation for regular files for many years (I can e.g. use |
Beta Was this translation helpful? Give feedback.
-
So if you see it, so does the server. So the server knows, at a perfectly reasonable point in time that the
It is a limitation arguably, but a limitation whose consequences in the particular case can be worked around in the server. The real "problematic" case is the one where the creation of
Does this mean on linux you don't see this problem at all. All summed up, I see a very thin case for change. But if you want to provide a patch and the patch is simple enough in complexity (and doesn't break anything), I might consider it.
Many servers get confused when large Git reset operations are done. Can't really blame them if you pull the rug completely under their feet. That's always time for a |
Beta Was this translation helpful? Give feedback.
-
Steps to reproduce:
emacs -q ~/repro-emacs/hello1(a directory)hello1.goM-x eglotgoplsRETtouch extra.goand I see adidChangeWatchedFilesevent in the*EGLOT …*buffer — good!mkdir newinternal, thentouch newinternal/extra.goand I see no event — this is unexpected.*Messages*buffer, I see:newinternaldirectory from my terminal, I see nofile-notify-add-watch. I conclude that Eglot does not re-evaluate recursive glob patterns when new directories are created.Beta Was this translation helpful? Give feedback.
All reactions