helix-editor
Support for EditorConfig
In #239 it was mentioned that support for EditorConfig would be nice, and it seemed like there was general agreement that we want to do that at some point.
I'm opening this issue just so it stays on our radar.
While we do that, I think we want to have a logo first to be able to put our editor in editorconfig.org
Should we use https://github.com/mrandri19/rust-editorconfig?
There's an open issue for that too (offering maintainership): https://github.com/mrandri19/rust-editorconfig/issues/13
I wonder if we could just attempt to parse it via TOML, it shares some similarities with INI.
There's also serde_ini, which seems like a reasonable way to go since we already have the serde dependency anyway.
It might just make sense to adapt https://github.com/zonyitoo/rust-ini. It seems like the only difference between .ini and .editorconfig are wildcard patterns in the section names.
Actually, I wonder if we need to do that at all and can just use it directly.
Edit: I checked it out and it seems like we can just use that crate directly without modifying anything. We just need to eliminate any duplicates (and only retain the first parsed value). This should be easy since the values are in the order they were parsed.
Dropping this here for future reference if we go for the manual implementation using an ini crate route, there is an editorconfig-plugin-tests repository containing instructions and sample files for testing.
Worst case scenario, we can just bind to https://github.com/editorconfig/editorconfig-core-c. But I don't think we'll need to.
What is the status of this feature's implementation? If there is a lack of manpower for it, then I'd be happy to contribute some.
Feel free :) I had some IRL things happen that prevented me from tackling this.
Is there a preference for wrapping editorconfig-core-c or writing something new in pure Rust? The spec seems simple enough for now.
https://github.com/zonyitoo/rust-ini seems to be able to parse it just fine.
I'll take that as a preference for writing a pure Rust implementation. That was my preference as well. :+1:
rust-ini appears unfit for this purpose, specifically because its section parser ends parsing at the first ] matched. That's fine for most INI, but Editorconfig allows regex-style character ranges in sections.
Either way, I think the largest challenge in writing a new Editorconfig implementation will be the globing behavior.
From there, integrating it doesn't seem particularly involved:
- Changing the indent style, character encoding, and line ending seem like they can be done with some calls in Document::open.
- Changing the tab width could be done by adding an
Option<usize>field toDocument, and makingDocument::tab_widthcheck that first before falling back to its current behavior. Let me know if there's a better approach. - Trimming trailing whitespace and inserting a final newline if one doesn't exist is harder. It seems like the place to do this is in Document::save_impl after the LSP formatting changes are applied.
- Helix doesn't currently support hard-wrapping (see #625), so the non-standard max_line_length property will be ignored for now.
It's been just over two weeks, so here's a status update.
I've been writing a new EditorConfig core. At the time of writing, it passes 161 of the 196 core tests, and some of the glob-related code quality is not what I'd like it to be (can't use the glob crate, unfortunately).
Once it passes all of the tests, I'd like to publish a 1.0.0 release to crates.io and add it as a dependency of Helix. Its only dependency is on std, but in the future it might also depend on unicode-segmentation. Alternatively, since I'm not expecting its public API to change as I bring the library into full test compliance, I could make a 0.3.0 release after fixing its main issues, and use that in Helix. Then, when 1.0.0 is done, all that should be necessary is a version bump. I expect it should work pretty well in the real world even without full compliance. Let me know!
I'll add that .editorconfig files also aren't highlighted at the moment, not sure if that's planned as a part of this issue
I'll add that .editorconfig files also aren't highlighted at the moment, not sure if that's planned as a part of this issue
It already has a PR and mention to this PR. https://github.com/helix-editor/helix/pull/8076
Can someone clarify what this issue is for? Support for editing .editorconfig files or for actually using them in Helix?
The latter would be of significant more interest to me... 👍
Support for using .editorconfig files so that it adjusts tabs, spaces, etc. defined therein.
Maybe a sidenote: When using prettier as formatter for JSON in Helix it somehow ignores the .editorconfig. But if you use it from the CLI urself it uses the .editorconfig
Maybe a sidenote: When using prettier as formatter for JSON in Helix it somehow ignores the .editorconfig. But if you use it from the CLI urself it uses the .editorconfig
That behavior is due to https://github.com/helix-editor/helix/issues/3596
Helix doesn't tell Prettier where the file is, so Prettier doesn't know where to look for an editorconfig
I'll comment here as well for people who aren't subscribed to the PR. I created ec2hx, a CLI tool to generate a project-specific helix configuration from an editorconfig file.
It can do some gnarly stuff that you wouldn't want to do manually. For example, a section header like [scripts/**] will generate a custom language definition for each language that helix supports, plus the necessary runtime queries to preserve syntax highlighting. trim_trailing_whitespace is supported via a built-in formatter.
The details about what is and isn't supported are documented in the readme. Check it out, maybe it suits your needs. And of course, bug reports are welcome.
