M. J. Fromberger

> it does **not**. We use enry + bblfsh supported languages api to check that bblfsh is able to parse a file. This api currently doesn't return `c#`, only `csharp`....

> It seems like C# is then not supported in any way other than language detection for the Engine. > I'd consider simply dropping mentions to C# on the release...

From the user's perspective, it'd be nice if we can avoid doing extra work for queries we know can't succeed. Once we have sorted out the mapping correctly, I think...

I have developed a theory about what may be causing this. I think what happens is roughly this: 1. When a directory is first watched, `watchDirectoryFiles` lists all its entries,...

> I think the simplest possible fix would involve making `sendDirectoryChangeEvents` repeat the link expansion that is done when the paths are registered, but it's possible there is a better...

The above is again partly wrong: It's not the path in `pathInfo` that matters, but what is entered in the `fileExists` map. That may be easier to fix: At kqueue.go:405...

Because of the special handling for broken symlinks, it's not enough to do path surgery: We need to either remember or recompute the status of the symlink's "goodness".

A lot of this indirection around symlinks appears to be motivated by the fact that `os.Open` follows symlinks. But it _is_ possible to get a file descriptor for a symlink,...

I'm coming around to the view that it may be a mistake to use the same logic for symlinks that are explicitly registered, as those appearing inside a directory watch:...

Thanks for the report. I intended that all the paths that allocate should report failure correctly, but it's entirely possible I missed some. Workaround aside, if you can point out...