helix on Chrome ?

[ide5kllc]

I am trying to build a fully in-browser IDE.

I am looking for an implemented-in-Rust editor with LSP support that can build on wasm32-unknown-unknown.

Is there currently anyway to build Helix for wasm32-unknown-unknown and run it in Chrome ?

It is okay if there is no file system access and I can only edit an in-memory buffer.

[the-mikedavis]

@archseer put some work into getting compilation working for WASM (so maybe he can say more here) but AFAIK Helix is not currently usable when compiled as WASM

[archseer]

Yeah it's not easy to do this right now without a lot of work and a separate frontend built in webGL. Alternatively helix-term frontend could probably run on xterm.js but that's also a lot of work.

[archseer]

There's a severely outdated attempt that ports more of the code but disables LSP https://github.com/helix-editor/helix/tree/gui

[ide5kllc]

Oh, I want LSP. I invested time learning about LSP internals and getting https://github.com/gluon-lang/gluon_language-server running in a webworker and talking to brower over postMessage. I'm not giving up LSP.

I am interested in hearing about "helix-term" on "xterm.js" -- I stumbled across xterm.js, but never gave it more thought. Is it conceivable that there is some crate TERM_EMULATOR that helix-term depends on, which currently does not compile on wasm32, but which we can fork, and stub in xterm.js in it?

Then, we take whatever API that TERM_EMULATOR exports, and using some Rust "ffi" (to JS) calls route it to xterm.js ?

[ide5kllc]

Not tested: https://github.com/segeljakt/xterm-js-rs claims to have Rust bindings to xterm-js.

Is this as "simple" as routing TERM_EMULATOR api to xterm-js-rs, or am I missing something important ?

[ide5kllc]

Another untested library: https://docs.rs/crate/xterm-js-sys/4.5.0-alpha0

[makemeunsee]

Hello,

I got curious and tried to 'resurrect' the gui branch and compile (parts of) Helix to wasm32.
That was a learning experience but it was too messy.
Even trying from promising commits like helix-view now builds on WASM or it compiles!.

Anyway, as I am only barely discovering the project, I have some questions about this whole ordeal:

• what component/aspect of lsp makes it (currently?) incompatible with the wasm32 target?
• what component/aspect of debugging (dap) makes it (currently?) incompatible with the wasm32 target?
• in the current state of Helix' code (as opposed to 2 years ago when the gui branch was created), what would be the high-level steps to port the code to wasm32? (e.g. decoupling helix-view from the terminal UI)

I get that tokio is a big offender in this regard, at least some features of it (see wasm supported features), so I'm interested in learning about the other ones.

Also for tree-sitter, the tree-sitter-facade and web-tree-sitter-sys that archseer was mentioning in the gui branch are now archived, but the Rust port of tree-sitter could be a better replacement (see this discussion).

Thanks for any input on this topic!

[makemeunsee]

I dove a bit into this and made decent progress, enough to warrant a self-reply I think:

• language servers and debugging tools are fully native, external processes, so are incompatible with wasm32 by nature, and integrating with hypothetical wasm32 compatible tools would require a significant refactoring of lsp and dap designs within Helix.
• massive feature gating is enough to enable compilation to wasm32; the challenge is to design and implement the integration with a web terminal backend.
• tree-sitter-c2rust works almost as a drop in replacement for tree-sitter, which is nice. How to provide the grammars remains to be solved.

Good news is I got the whole project (minus excluded features) to build to wasm32, but there remains a lot to be done to make it usable.

This is the branch where it lives: https://github.com/makemeunsee/helix/tree/wasm32