Conversation
This helps to handle the case where the LSP client restarts the server several times in rapid succession, as can happen with VS Code, especially when developing lsp-dylan and introducing random bugs.
This delays opening the log file until the 'initialize' LSP handler is called so that we know the workspace directory, which required a bit of a hack: store the log file name in the params of the 'initialize' method.
This doesn't need to be a submodule. Normally it will come via the VS Code extension marketplace and for development it can be checked out anywhere.
The output is now logged to dylan-lsp-server.log. This papers over the problem mentioned in dylan-lang#47.
The quantity of hover messages makes the dylan-lsp-server.log difficult to use. If necessary to debug textDocument/hover itself the method name can be removed from `$do-not-log-methods`.
This removes the global variables `*project*` et al and instead stores the project in the `<document>` instance when a file is opened. As a side effect this meant changing the parameter lists of various functions to pass a document in. Uses the Deft `workspace` module to determine the library that each source file belongs to when `textDocument/didOpen` is called. Moved the `<document>` class and some functionality specific to documents into a new file, documents.dylan. Introduced a new macro, `with-lsp-params`, that enables binding parameters by name, for example "textDocument.uri". This is the first step to fixing dylan-lang#46.
If a project hasn't been built yet we need to get a build started so that LSP operations will work.
Specifically, we need to track diagnostics for the most recent build of a project so that we can determine whether we need to send an empty set of diagnostics back to the client to clear the old ones. The diagnostics need to be associated with the project because with the old code (one global variable) we would clear all diagnostics for project-a if project-b was compiled. Also moved session objects to their own file and renamed session slots to be less verbose.
I don't see much use for it. It only suppresses a backtrace and in general we want to see the backtrace.
`file-locator` doesn't work with the last argument being something like "foo/bar.dylan" so we have to use `merge-locators` instead.
No longer used or needed, as far as I know.
There was a problem hiding this comment.
In general, do we want the log files in the workspace dir (and not tmp?) Will this not clutter things up and need them to be added to .gitignore?
There was a problem hiding this comment.
One problem with putting them in /tmp is overlap when using LSP on multiple projects independently; possibly while using multiple Emacs, and/or VS Code.
In Emacs there's a setting to add a --log command-line option. Maybe we should add one in VS Code also? (And we should make it possible to turn off the log file completely.)
There was a problem hiding this comment.
good point. Sometimes the PID is used as part of the filename. Would that help?
| *standard-output* := _stdout; | ||
| *standard-error* := _stderr; | ||
| if (~empty?(out)) | ||
| log-warning("stdout: %s", out); |
There was a problem hiding this comment.
Will this end up in the log file eventually? I wonder, is it possible to redirect the output of the logging library so it comes back through LSP (via LogMessage or LogTrace)?
There was a problem hiding this comment.
Our stderr logging already shows up in Emacs in the *lsp-dylan::stderr* buffer and in the "OUTPUT" tab in VS Code when you select "Dylan Language Server" from the pull-down menu. But I'm still not sure if our file log is completely redundant. Maybe we can remove the --log option in the long-run and only log to stderr.
testproject/.vscode/settings.json
Outdated
There was a problem hiding this comment.
This was just to have a minimal project to hand whilst testing LSP, so yes it doesn't belong in the repo
2 participants
The major change here is to allow opening any number of OD projects so that if
textDocument/definitionjumps you to a new file in a different project, that project can be opened successfully. There's much more to do in this regard but at least it works for me when I jump into dependency code in the_packagessubdirectory of my workspace.This PR will be a draft until dylan-lang/deft#69 is merged and a new version of Deft is published.
Makes progress on #46