-
Notifications
You must be signed in to change notification settings - Fork 62
LSP-based infoview #30
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
Conversation
@@ -163,9 +160,6 @@ export class LeanClient implements Disposable { | |||
} | |||
}, | |||
} | |||
this.setProgress(Object.assign({}, ...workspace.textDocuments |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removing this changes the semantics slightly in that yellow bars only appear when the server actually begins compiling the header. I think this is nice, as visually indicates things are working.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have extremely strong feelings about this, but it was very much intentional. When opening a Lean file, I'm interested in whether there are errors or not. The progress bars allow me to distinguish the states of "no errors because Lean hasn't compiled this part yet" and "no errors because the proof is fine".
This is the same reason why I said that the fileProgress notification should be sent before processing is started (in leanprover/lean4#503). The important information is not that Lean is still running, but that it is not finished yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see your point. The only real difference is that with this change, if the server fails to start the gutters won't appear, whereas before they'd be there even though nothing is actually being processed. You still know that the lack of errors is due to server failure because there will be the "server failed to start" popup. IMO this way it's clearer when things have failed, and when things are actually compiling (where we do send server notifs before starting compilation as you note), and you can still clearly tell why there are no errors. But if you still disagree, I'm happy to revert this change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, if this only happens with a dead server then it's a non-issue. In that case you already get a lot of errors anyhow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, there are also no gutters between exec lean --server
and "lean --worker
sends progress @ 0
". This is a few ms right now, but I suppose it could be a problem with a bad plugin which takes long to initialize. We could show progress then.
/** Apply edits to the workspace. */ | ||
applyEdits(edits: TextDocumentEdit[]): Promise<void> | ||
/** Insert text into a document. When `pos` is not present, write at the current cursor location. */ | ||
insertText(text: string, kind: TextInsertKind, pos?: TextDocumentPositionParams): Promise<void> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sadly the range of things which can be done with TextEdit
without knowing the file contents (and for now we don't really need to track them in the infoview) is quite small, so reinstated this API.
I've tried it out a bit now. Some comments:
|
In Emacs I quickly got used to it, and I believe @leodemoura liked them as well. I haven't seen this PR in action yet though, it might be a case of color schemes. Here is what it looks like in Emacs for me currently: |
I get something very similar on my machine, and yes I like it too :) |
fixed
I made an attempt at how this should work but cannot test it without the PAT, so feel free to change things. Note the slightly weird |
This is also the current behaviour, but I removed the newline.
I removed the |
Oops, I didn't notice that. You're right of course.
I think that was a different bug. I mean the following:
|
I fixed the type disappearing. As for the double-move, I also observed that before but can't anymore. I will wishfully think it disappeared along with one of the recent changes, but let me know if it's still buggy. Also the pin movement is still incorrect if you insert a newline before |
I still get the double-moves. |
Fixed now, hopefully. This was only observable on development builds because it was (intentionally, to catch this kind of bug) triggered by |
@gebner I've been test-driving this since the PR and it seems to work fine. I think it's good to go. Though I probably wouldn't release a new version until there are actually new features (WIP) using the LSP API. |
Great! I'll make a release so that we get some free testing! |
"version": "0.0.31", | ||
"publisher": "leanprover", | ||
"engines": { | ||
"vscode": "^1.57.0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Vtec234 Do you remember why you had to bump the vscode minimum version requirement here? Does this PR use any new vscode feature?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wanna say it was something to do with the webview API, but I honestly don't remember, sorry.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No problem. We just run into an issue where the vscode-languageclient library has a hard requirement on the latest vscode version, and then I checked out the version requirement we had in package.json
.
In any case, please don't bump this version unnecessarily. Old vscode versions won't install extensions that are not compatible with them.
This PR splits the infoview into a separate NPM package independent of VSCode, and based on a more general editor<->infoview API based on LSP. Changes include:
vscode-jsonrpc
.textDocument/didChange
.info.tsx
. UI code is difficult, but I tried to separate the concerns of pausing and fetching goals into different and maybe reusable components.I apologise for making the development a bit hard to follow. I made commits to a separate repo before copying the files here. They can be browsed.
There are quite a lot of changes, and while I tried testing all functionality I expect there to be some breakage. Still to be fixed:
now a general "make text edit" API)