search

ratmice / nimbleparse_lsp

lsp server for grmtools lex & yacc
Other
7 stars 1 forks source link

tame the gigantic conflicts diagnostic #7

Closed ratmice closed 1 year ago

ratmice commented 2 years ago

The gigantic conflicts diagnostic needs a lot of experimentation. In theory each state may be separated out into a 'related diagnostic', providing a jump location for each individual state.

But diagnostics are typically fairly short and editor UI's reflect that. vscode even with the, diagnostic output window maximized doesn't read easily, nvim lsp.diagnostics.open_float() doesn't scroll.

I'm not certain diagnostics are actually going to be the right thing for this information, It may be that we want an LSP extension which provides a list of jump targets.

ratmice commented 2 years ago

Interesting papers:

Visual exploration of visual parser execution Finding counterexamples from parsing conflicts

Papers about SAIDE A Methodology for Removing LALR(k) Conflicts An LALR Parser Generator Supporting Conflict Resolution

ratmice commented 2 years ago

FWIW, I filed https://github.com/microsoft/language-server-protocol/issues/1458 and https://github.com/microsoft/language-server-protocol/issues/1461 related to this, I think currently we could so something hacky, by generating a file directly on the filesystem containing the conflict information, lets call it conflict_report.txt then emitting a diagnostic which links to file://.../conflict_report.txt via relatedDocuments.

I hestitate to do it for a few reasons:

  1. I don't think this will work with wasm based extension,
  2. How would we invalidate it?
    • Delete the file (It may still be open in the editor but shown as deleted)
    • Truncate it and add some message to the file (assuming we open it as read-only, it should notice and reflect current state)
  3. Writing random files to potentially version controlled sources is just not nice, I'd rather keep this within the editor.

Anyhow I just don't realistically see all the conflict information fitting within the UI that diagnostics are currently limited to.

The writing a report directly to the filesystem and linking to that, does have the benefit of being something we can emit now without changing LSP and we don't actually work as a web/wasm based extension yet. So I may need to do that despite the fact that I find it terrible. Because it doesn't really seem like it will be a fast process to add a mechanism here to LSP.

Option 2:

Adding an lsp extension, I think we'd have to basically emit an entire replacement for Diagnostic, and client side handlers for this extension. Doesn't seem like the typical extension, because it is an alternative to rather core lsp functionality and involves quite a bit on the editor side.

ratmice commented 1 year ago

While there is probably a lot more that can be done here, I'm going to close as PR #10 and #18 have generally improved things, such that the conflict output is no longer gigantic