Skip to content

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

Closed
michaelpj opened this issue Jan 29, 2022 · 0 comments · Fixed by #404
Closed

Move VFS to lsp rather than lsp-types? #394

michaelpj opened this issue Jan 29, 2022 · 0 comments · Fixed by #404

Comments

@michaelpj
Copy link
Collaborator

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.

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.
michaelpj added a commit to michaelpj/lsp that referenced this issue Feb 6, 2022
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
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants