Skip to content
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

TODO #6

Open
10 of 15 tasks
certik opened this issue Nov 4, 2024 · 0 comments
Open
10 of 15 tasks

TODO #6

certik opened this issue Nov 4, 2024 · 0 comments

Comments

@certik
Copy link
Contributor

certik commented Nov 4, 2024

Currently here: lfortran/lfortran#4808

And:

  • Be more specific with activation events to improve performance (see: Activation Events).
  • Add support for automated testing and ensure the server and client are adequately tested (Add a CI to test this extension #3)
  • Investigate whether throttling the response to content-change events is necessary, and if so, whether the implementation is correct.
  • Return diagnostic severity from lfortran rather than hardcoding it to DiagnosticSeverity.Warning (code=2).
  • Use the diagnostics from lfortran as verbatim as possible (rewriting them does not appear necessary, with the exception of a few things like the severity code).
  • Return valid symbol kinds from lfortran rather than hardcoding them to SymbolKind.Function.
  • Rewrite loops for efficiency.
  • When possible, pass the URI of an edited text document to lfortran instead of the path to a temporary copy of it.
  • Add core language features documented here.
  • Persisting the LFortran session (lfortran lsp server): cache ASR trees within lfortran, cache context, etc. for performance; it should be able to save and restore sessions.
  • Refactor code completion to query a trie over a document's symbols; this should probably be done within the client but may be done within lfortran.
  • Syntax and semantic highlighting
  • Publish automatically using GitHub CI #4
  • pulling the path to lfortran from the user's $PATH and make it configurable via UI
  • integration with a build system (fpm, cmake): for now we'll assume the user compiles the full project and has all .mod files available, so that when a given file is edited, lfortran can just load all required .mod files. Later we can either make LFortran cooperate with fpm to know where other files are and how they must be compiled, or the extension can cooperate with fpm.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant