@matklad , might I ask you why we shouldn't expose feature flags structure to UI, @Laurențiu Nicola and I are convinced that this affects UX... We would like to declare them in
package.json at least temporarily, while we don't generate it from our source code
I don't know what's the right answer here
I would be 100% with generating that bit of settings from a Rust declaration
I would be less OK with just manually syncing things, or keeping source of truth in package.json
Opened https://github.com/rust-analyzer/rust-analyzer/issues/3189 for the overall configuration design discussion
I think sync'ing them manually is fine for now because 1. this affects users right now, 2. there's very few of them, 3. if we use a prefix to differentiate these preferences, the client-side work to support it (notifying the server that a flag has changed) will be useful when switching to something generated automatically
Yeah, that's reasonable. They reason why I am not 100% is that doing that relives pressure from this issue for VS Code and, all other things being equal, I'd prefer not to single out this editor more than it already is
Still, generating the
package.json parts automatically will not help other editors, will it? Because each LSP client will have a different way to configure these.
It will, as it will also generate docs. But this is just a minor point
Then a plan here might be to:
package.jsonand implement a way to toggle them from the Code extension
xtaskto read the doc comments on that struct (or the different format) and produce docs for them
xtaskto generate the
We could also describe them in e.g. JSON schema and optionally generate Rust code from that.
SGTM, though I am not sure about 2. The problem main problem with strong types is that we want to separate LSP settings from analyzer settings. String types allow us to have a runtime dep there
We may declare feature flags structs specific to non-lsp crates and map lsp-feature-flags to non-lsp ones by
impl From. Making them a hashmap I would think that we would want to dynamically mutate our feature flags, though this doesn't happen in practice, hence simple mapping is more convenient I think
Or store them in a struct on the server and use strings at the interface
@std::Veetaha generating code from the JSON schema should work, right?
Can it also store comments/descriptions?
I'd rather avoid JSON schema and use the appoach we use to gen ast
declare a rust struct with a macro, generate things from this struct
that avoids build-time dependency on parsing json/toml/ron whatever
Jason schema do stores metadata "title", "description" props, tho I am totally okay with the approach we have in ast gen. But, @matklad, does my proposal with separating the API and mapping between different structs seem reasonable?
It does, though I think hash-map vs typed API is a minor point here
Like, I do thing that either would work fine, and that both would be indistinguishable for users
Right, indistinguishable, that's just a server impl detail
Sorry, I might've missed the point
Anyway, what was the initial reason we switched from Ron? By parsing Ron you mean time consuming?
Mainly to improve compile times, and also to reduce overall complexity
So, do we work on configuration design first? I don't think that adding feature flags declaration to
package.json would be any noticeable tech debt, amending
package.json is the only thing it requires...
I am ok with r+ whatever changes to package.json/TS to make better short term.
For backend changes, I think I'll need to spend some time familiarizing myself with the relevant LSP APIs first, and that probably won't happen this week
Okay, I'll add relevant feature flags to
Also, as a side not, I'd suggest using
r+ word not so often, because this is very ad hoc.