Will rustowl provide the binary as release assert like other language server?

[owlx56]

As the title says, this will be more convenient for editors to download rustowl instead of building it.

[cordx56]

Thanks for your comment!

It’s a difficult issue. We can easily provide a prebuilt binary, but users still need to install the nightly toolchain and some components.
Currently, this is done by running commands in the build script.
Even if we distribute a prebuilt binary, we still need to write an installation script.
I’m not sure what the best way to distribute RustOwl is.

[MuntasirSZN]

Not found? Download it and set it up according to os. (Needs root perms afaik)

[MuntasirSZN]

├── build.rs
├── Cargo.lock
├── Cargo.toml
├── docs
│   ├── assets
│   │   ├── readme-screenshot-2.png
│   │   ├── readme-screenshot-3.png
│   │   ├── readme-screenshot.png
│   │   ├── rustowl-logo-dark.svg
│   │   ├── rustowl-logo.svg
│   │   ├── vs-code-cursor-on-unwrap.png
│   │   ├── vs-code-cursor-on-unwrap-visualized.png
│   │   └── vs-code-progress.png
│   ├── lsp-spec.md
│   └── usage.md
├── example
│   ├── all.rs
│   └── scope.rs
├── integrations
│   ├── emacs
│   │   └── rustowl.el
│   ├── neovim
│   │   ├── ftplugin
│   │   │   └── rust.lua
│   │   └── lua
│   │       └── rustowl
│   │           ├── config.lua
│   │           ├── highlight.lua
│   │           ├── init.lua
│   │           ├── lsp.lua
│   │           └── show-on-hover.lua
│   └── vscode
│       ├── esbuild.js
│       ├── eslint.config.mjs
│       ├── LICENSE
│       ├── package.json
│       ├── README.md
│       ├── rustowl-icon.png
│       ├── sample.rs
│       ├── src
│       │   ├── bootstrap.ts
│       │   ├── extension.ts
│       │   └── schemas.ts
│       ├── tsconfig.json
│       └── yarn.lock
├── LICENSE
├── README.md
├── rust-toolchain.toml
├── src
│   ├── bin
│   │   └── rustowl.rs
│   ├── cli.rs
│   ├── core
│   │   └── analyze.rs
│   ├── core.rs
│   ├── lib.rs
│   ├── lsp
│   │   ├── decoration.rs
│   │   └── progress.rs
│   ├── lsp.rs
│   ├── main.rs
│   ├── models.rs
│   ├── shells.rs
│   ├── toolchain_version.rs
│   └── utils.rs
└── version.sh

Unrelated but this structure looks really good.

Want this setup?

[cordx56]

Want this setup?

Yes! but can Neovim find plugin if moving ftplugin and lua dir into under integrations?

[MuntasirSZN]

Want this setup?

Yes! but can Neovim find plugin if moving ftplugin and lua dir into under integrations?

I thought of this and found a nasty plan. Neovim package managers accept a branch prop, so we can write a ci script so it syncs the neovim folder with a Branch (named neovim) in the repo.

Also, i think we should migrate the intellij and nix flake in the repo, for the future. We need maintainers afaik.

[cordx56]

@MuntasirSZN OK! ongoing discussion is out of scope for this discussion title. So I will reply at #86 . Let's discuss about this and cite comments here if needed.

[cordx56]

@MuntasirSZN This thread is too long and it is not matched with discussion title.
Let's move to #86 !