I am excited to see progress on macro expansion in hover document (PR #21928), but I noticed that only Rust and TOML files are included.
I did see PR #21968 which hard-codes the .md extension, and it is understandable given that it is the most common use case.
I noticed the setting rust-analyzer.vfs.extraIncludes in VSCode and I thought, perhaps it would be worthwhile to have another setting, such as rust-analyzer.vfs.extraExtensions, with a default value of ["md"].
This way users could opt-out of including Markdown files, and would also be able to opt-in to other plaintext files, be that a diagram in a .txt file, a configuration file in a .json, .yaml, and so on.
While in some cases those files could be stored embedded in other markdown files (inside language-identifying code blocks), this would require manual duplication of the configuration into markdown files.
The primary changes I am thinking are replacing L307
dirs.extensions.push("md".into());with
dirs.extensions.extend(config.vfs.extraExtensions);
I did read Contributing > Implementing a new feature, which advises that I would receive feedback on the desirability of this feature before beginning an implementation.
I don't know the structure of rust-analyzer, or how to access the configuration data in load-cargo/src/lib.rs, so if this is a desirable feature, that initial direction would be helpful.
Thank you.
I am excited to see progress on macro expansion in hover document (PR #21928), but I noticed that only Rust and TOML files are included.
I did see PR #21968 which hard-codes the
.mdextension, and it is understandable given that it is the most common use case.I noticed the setting
rust-analyzer.vfs.extraIncludesin VSCode and I thought, perhaps it would be worthwhile to have another setting, such asrust-analyzer.vfs.extraExtensions, with a default value of["md"].This way users could opt-out of including Markdown files, and would also be able to opt-in to other plaintext files, be that a diagram in a
.txtfile, a configuration file in a.json,.yaml, and so on.While in some cases those files could be stored embedded in other markdown files (inside language-identifying code blocks), this would require manual duplication of the configuration into markdown files.
The primary changes I am thinking are replacing L307
with
I did read Contributing > Implementing a new feature, which advises that I would receive feedback on the desirability of this feature before beginning an implementation.
I don't know the structure of
rust-analyzer, or how to access the configuration data inload-cargo/src/lib.rs, so if this is a desirable feature, that initial direction would be helpful.Thank you.