Persistent editor settings and customizable keybindings
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 14.6k
- Forks
- 734
- Avg merge
- 8h 40m
- Merged PRs (30d)
- 4
Description
Hello maintainers,
I've gone through the existing issues and PRs, and it seems there's no concrete plan yet for two features I'd find really useful: persistent editor settings and customizable keybindings.
Before I start writing any code, I'd like to propose an approach and hear the team's thoughts.
Feature 1: Persistent Editor Settings
The project already has a settings.json system (settings.rs) with cross-platform path resolution. I'd like to extend it to also persist buffer-level editor states.
Proposed new fields:
{
"editor.autopairs": true,
"editor.wordWrap": true,
"editor.useSpaces": true,
"editor.tabSize": 4,
"editor.newlineStyle": "lf"
}
- No new dependencies: reuse the existing json parser and settings.json infrastructure.
- If a field is missing, behavior falls back to current defaults.
- The binary size will not increase by much, and this is a lightweight functional addition.
Feature 2: Customizable Keybindings
Currently, shortcuts like Ctrl+R(replace) are hardcoded in main.rs. I propose allowing users to override these via settings.json, so that users can use other shortcuts like Ctrl+H to replace.
Proposed new field:
{
"keybindings": {
"editor.action.newFile": "ctrl+n",
"editor.action.openFile": "ctrl+o",
"editor.action.save": "ctrl+s",
"editor.action.wordWrap": "alt+z"
}
}
Also no new dependencies, all settings are optional, and the binary size can be well controlled.
Proposed Next Steps
I'd be happy to implement these if the direction looks good.
Specifically, I would like feedback on:
- Is the team open to these being implemented incrementally (persistence layer first, without waiting for the full settings page UI from #22)?
- Is it okay to reuse the existing
settings.jsonfor editor settings, or do you prefer a dedicated file likekeybindings.jsonfor keybindings?
Looking forward to your thoughts!
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading settings.rs to understand the existing settings.json path resolution and defaults, then inspect the hardcoded shortcuts in main.rs. Review the relationship to the settings page proposed in #22. The issue is ready only after maintainers decide whether to combine both features and use settings.json or a separate keybindings.json.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- cli, developer-experience
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100