UPDATE: This PR now specifies the dependence on Rust Analyzer through the install instructions.

Currently, installing the extension for developers, depends on Rust Analyzer. That is due to "type": "cargo" is a construction from rust-analyzer.

~~Instead, this just invokes cargo as a shell command.~~

Adds a release.yml github actions workflow that builds the server binary and extension for every target listed in https://code.visualstudio.com/api/working-with-extensions/publishing-extension#platformspecific-extensions.

The action runs on new git tags, and creates a release with all the binaries and vsix, and calls vsce publish. You'll need to add a VSCE_PAT github secret (how to get access token) and add a publisher field to the package.json.

• add png version of icon
• change extension.ts to look for bundled executable first, falls back to typst-lsp[.exe] (could also be configurable via vscode settings)
• add LICENSE file and package.json properties to addons/vscode
• add esbuild for bundling and change package.json scripts
  • npm run package builds .vsix, bundles using esbuild minified
  • npm run compile bundles using esbuild with source maps
  • npm run check runs tsc to check typescript
  • npm run lint/lint-fix as before

If you'd like to have anything changed let me know :)

Fix the following error when opening a singe file (with no folder in the workspace)

thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/main.rs:26:29

fixes #41 fixes #36

• Component:
  • [ ] VSCode Extension
  • [x] VSCodium Extension
  • [ ] LSP (used with other editor)
• Extension version: 0.4.0
• LSP version: 0.4.0
• OS version and name: OpenSUSE Tumbleweed, snapshot 20230402

• [X] I am on the latest stable version of the extension/LSP.
• [X] I have searched the issues of this repo and believe that this is not a duplicate.

Issue

Since the latest release (0.4.0 - this did not occur in 0.3.2), when opening a .typ file in a workspace whose path contains symlinks, the extension seems to automatically resolve the symlinks, and, when you click on errors or similar to check where they are, it opens the file again, but on the actual absolute path instead of the symlinked path. This has become somewhat of an annoyance, as my usual workspace uses symlinks in its path.

Reproduction Steps

1. Create a folder, e.g. mkdir /tmp/a
2. Create a typst file in there with an error, e.g. echo "soajdfo()asdfo" >> /tmp/a/bad.typ
3. Create a symlink to the folder, e.g. ln -s /tmp/a /tmp/b
4. Open the symlink as a workspace in Code/Codium, e.g. codium /tmp/b
5. Open the bad.typ file, and edit it slightly (e.g. write "abc" at the end) to ensure it is not opened as a preview (but for editing)
6. Open the errors panel, and click the error (to be taken to it)

Expected Result: it just takes you to the error in the currently open file Actual Result: it opens the file again, as if it was external to the current project, but in the absolute path (with symlinks resolved) instead of relative to the current (symlinked) directory

Thanks for your hard work on this awesome extension. But I think it depends on a considerably outdated version of Typst. Given that the new Typst 0.2.0 has introduced brand new syntaxs like unpacking (see https://github.com/typst/typst/releases/tag/v0.2.0), I think it is a good time to bump typst version to a newer one.

I have tested the compilation and installation, they work fine, but I do realize there are some incompatibility with the newer syntax. I am not that familiar with Rust so help needed here from you capable guys. Take this PR as a reminder to upgrade typst version then, maybe?

This PR is in response to #69.

Discussion

I am not really happy how the file extension/type is currently manually changed from .typ to .pdf. I'll happily implement something more robust if somebody has a recommendation.

Process typst-lsp caused out of memory and was killed. It eat 8+Gb session. A single main.typ file was editted for several hours.

• Component:
  • [ ] VSCode Extension
  • [ ] VSCodium Extension
  • [x] LSP (+ neovim)
• Extension version:
• LSP version: 0.3.1-1
• OS version and name: ArchLinux

• [x] I am on the latest stable version of the extension/LSP.
• [x] I have searched the issues of this repo and believe that this is not a duplicate.

• [x] I have searched the issues of this repo and believe that this is not a duplicate.
• [x] I have searched the discussions and believe that my question is not already covered.

Feature Request

The memory usage of the typst-lsp grows linearly with time, until after a few hours of intense usage it reaches nearly 32 GB of RAM. Most of this seems to be unused entries in typst's comemo cache, since swapping doesn't hurt performance much. Could the LSP be configured to perform regular evictions of old cache entries, via https://docs.rs/comemo/latest/comemo/fn.evict.html?

Right now clippy lints are not causing an error in CI, they just raise warnings (e.g. https://github.com/nvarner/typst-lsp/actions/runs/4523508185/jobs/7966681325)

Is that something that we want to change to enforce consistency?

The following command causes errors on clippy warnings: cargo clippy -- -Dwarnings

• [x] I have searched the issues of this repo and believe that this is not a duplicate.
• [x] I have searched the discussions and believe that my question is not already covered.

Feature Request

Add an option to use typst-lsp from PATH (or any absolute path), instead of relying the bundled excutable.

The bundled executable will not work on every linux distro.

Perhaps a dumb question, but I installed the VSCode extension (on Windows 10), created a .typ file, entered some random text, saved it. Nothing happens. No pdf is created, nothing in Output window. VSCode is showing "Typst" for document and extension settings for PDF creation are set "onSave". Am I missing something obvious? Also, perhaps add a paragraph to readme on what to expect (i.e. if configured properly, a NAME.pdf should appear alongside original text).

• Component:
  • [x] VSCode Extension
  • [ ] VSCodium Extension
  • [ ] LSP (used with other editor)
• Extension version: v0.4.0
• LSP version: v0.4.0
• OS version and name: macOS 13.3

• [x] I am on the latest stable version of the extension/LSP.
• [x] I have searched the issues of this repo and believe that this is not a duplicate.

Issue

Looks like something is wrong with the TextMate grammar as modules are scoped as entity.other.interpolated.typst.source.typst instead of entity.name.function.typst.source.typst

Can be quickly reproduced by making a module.typ file with #let hello_world() = [hello world!] and then a test.typ file with #import "module.typ" #module.hello_world()

Logs

• [x] I have searched the issues of this repo and believe that this is not a duplicate.
• [x] I have searched the discussions and believe that my question is not already covered.

Feature Request

Pull request #72 seems to create or open the generated pdf in VSCode only after push the "Show PDF" Button. Could you please make the pdf file auto refreshed after compiling like the latex/markdown extensions in vscode.

• [x] I have searched the issues of this repo and believe that this is not a duplicate.
• [x] I have searched the discussions and believe that my question is not already covered.

Feature Request

Could we have a new setting for additional font directories? Just like the --font-path option in typst. It would be useful when using fonts that are not embedded. Also some dependent settings like whether to search recursively. Thanks for your contributions! I am enjoying using this extension!

• Component:
  • [x] VSCode Extension
  • [ ] VSCodium Extension
  • [ ] LSP (used with other editor)
• Extension version: 0.3.2
• LSP version: (not sure. should be the one bundled with the extension)
• OS version and name: OpenSUSE Tumbleweed 20230322, VSCode 1.77.0

• [x] I am on the latest stable version of the extension/LSP.
• [x] I have searched the issues of this repo and believe that this is not a duplicate.

Issue

First big thanks for the fabulous work!

Here's an issue with the rendering in the editor view of VSCode:

But the view is correct when the styled parts are put in the same line:

Logs

N/A

• Component:
  • [x] VSCode Extension
  • [ ] VSCodium Extension
  • [x] LSP (used with other editor)
• Extension version: v0.3.1
• LSP version:
• OS version and name:

• [x] I am on the latest stable version of the extension/LSP.
• [x] I have searched the issues of this repo and believe that this is not a duplicate.

Issue

Reproduce:

• [VSCode Extension setting] Export PDF: onSave and onType
• Folder structure

.
├── other.typ
├── main.pdf
├── main.typ
└── template.typ

• In main.typ:

#include "other.typ"

When other.typ is modified, the PDF will not be rendered automatically.

• [x] I have searched the issues of this repo and believe that this is not a duplicate.
• [x] I have searched the discussions and believe that my question is not already covered.

Feature Request

Implement the outline of the typst source file and display the outline in the VSCode outline view. This feature might require building the AST of a typst source file.