-
Notifications
You must be signed in to change notification settings - Fork 95
Move VFS to lsp rather than lsp-types? #394
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Labels
Comments
michaelpj
added a commit
to michaelpj/lsp
that referenced
this issue
Jan 30, 2022
This started as an attempt to bubble up errors from the VFS as actual errors and return them to the user via the LSP response. However, in fact VFS operations occur in response to notifications, which don't have responses. So all we can do is log the error and drop the change, which is okay. However, that made me look at how the logging works. At the moment we use `hslogger`, which is fine, but isn't so great when it's plugging into part of a larger system. For example, we might want to have a global log handler that sends error-level logs to the client as messages, or uses the `logMessage` method of the LSP spec. But there's no way to intercept the messages sent by the VFS currently. So I switched over to using `co-log-core`, which is also the direction that [HLS is going](haskell/haskell-language-server#2558). `co-log-core` is also a lightweight dependency. It's suboptimal for `lsp-types` to depend on a logging library, however, but that should be fixed when we do haskell#394.
michaelpj
added a commit
to michaelpj/lsp
that referenced
this issue
Jan 30, 2022
This started as an attempt to bubble up errors from the VFS as actual errors and return them to the user via the LSP response. However, in fact VFS operations occur in response to notifications, which don't have responses. So all we can do is log the error and drop the change, which is okay. However, that made me look at how the logging works. At the moment we use `hslogger`, which is fine, but isn't so great when it's plugging into part of a larger system. For example, we might want to have a global log handler that sends error-level logs to the client as messages, or uses the `logMessage` method of the LSP spec. But there's no way to intercept the messages sent by the VFS currently. So I switched over to using `co-log-core`, which is also the direction that [HLS is going](haskell/haskell-language-server#2558). `co-log-core` is also a lightweight dependency. It's suboptimal for `lsp-types` to depend on a logging library, however, but that should be fixed when we do haskell#394.
michaelpj
added a commit
to michaelpj/lsp
that referenced
this issue
Jan 30, 2022
This started as an attempt to bubble up errors from the VFS as actual errors and return them to the user via the LSP response. However, in fact VFS operations occur in response to notifications, which don't have responses. So all we can do is log the error and drop the change, which is okay. However, that made me look at how the logging works. At the moment we use `hslogger`, which is fine, but isn't so great when it's plugging into part of a larger system. For example, we might want to have a global log handler that sends error-level logs to the client as messages, or uses the `logMessage` method of the LSP spec. But there's no way to intercept the messages sent by the VFS currently. So I switched over to using `co-log-core`, which is also the direction that [HLS is going](haskell/haskell-language-server#2558). `co-log-core` is also a lightweight dependency. It's suboptimal for `lsp-types` to depend on a logging library, however, but that should be fixed when we do haskell#394.
michaelpj
added a commit
to michaelpj/lsp
that referenced
this issue
Jan 30, 2022
This started as an attempt to bubble up errors from the VFS as actual errors and return them to the user via the LSP response. However, in fact VFS operations occur in response to notifications, which don't have responses. So all we can do is log the error and drop the change, which is okay. However, that made me look at how the logging works. At the moment we use `hslogger`, which is fine, but isn't so great when it's plugging into part of a larger system. For example, we might want to have a global log handler that sends error-level logs to the client as messages, or uses the `logMessage` method of the LSP spec. But there's no way to intercept the messages sent by the VFS currently. So I switched over to using `co-log-core`, which is also the direction that [HLS is going](haskell/haskell-language-server#2558). `co-log-core` is also a lightweight dependency. It's suboptimal for `lsp-types` to depend on a logging library, however, but that should be fixed when we do haskell#394.
Merged
michaelpj
added a commit
to michaelpj/lsp
that referenced
this issue
Feb 6, 2022
This started as an attempt to bubble up errors from the VFS as actual errors and return them to the user via the LSP response. However, in fact VFS operations occur in response to notifications, which don't have responses. So all we can do is log the error and drop the change, which is okay. However, that made me look at how the logging works. At the moment we use `hslogger`, which is fine, but isn't so great when it's plugging into part of a larger system. For example, we might want to have a global log handler that sends error-level logs to the client as messages, or uses the `logMessage` method of the LSP spec. But there's no way to intercept the messages sent by the VFS currently. So I switched over to using `co-log-core`, which is also the direction that [HLS is going](haskell/haskell-language-server#2558). `co-log-core` is also a lightweight dependency. It's suboptimal for `lsp-types` to depend on a logging library, however, but that should be fixed when we do haskell#394.
michaelpj
added a commit
to michaelpj/lsp
that referenced
this issue
Feb 19, 2022
This started as an attempt to bubble up errors from the VFS as actual errors and return them to the user via the LSP response. However, in fact VFS operations occur in response to notifications, which don't have responses. So all we can do is log the error and drop the change, which is okay. However, that made me look at how the logging works. At the moment we use `hslogger`, which is fine, but isn't so great when it's plugging into part of a larger system. For example, we might want to have a global log handler that sends error-level logs to the client as messages, or uses the `logMessage` method of the LSP spec. But there's no way to intercept the messages sent by the VFS currently. So I switched over to using `co-log-core`, which is also the direction that [HLS is going](haskell/haskell-language-server#2558). `co-log-core` is also a lightweight dependency. It's suboptimal for `lsp-types` to depend on a logging library, however, but that should be fixed when we do haskell#394.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm not really sure why it is where it is, it seems to belong more to the "actual LSP server" code than the "type definitions for the LSP protocol" code.
The text was updated successfully, but these errors were encountered: