Feature Description
Hello @blopker ,
First, thank you for creating codebook! As a VS Code user for years, I've used CSpell Checker as my first choice, but I grew tired of its insensible memory consumption (often 300~500MB for a single file). Finally, I found this project provides similar features but with less source consumption. I'm a big fan now and excited about its potential.
As for VS Code extension, it's clear that it is in a very early stage and has many aspects to improve. So I'm opening this issue to propose a series of enhancements that would align it more closely with VS Code's ecosystem conventions and improve the overall user experience. I understand some conventions are quite different from other editors, so some of them may be quite tricky to handle.
I believe these changes would make codebook even more attractive to VS Code users and help get the extension ready for publishing. I'm happy to discuss them and would be willing to contribute pull requests to implement them incrementally.
Use Case
-
Code actions: Although VS Code has great support for code actions of LSP, using them frequently (for operations like "Add word to dictionary") can introduce some friction.
-
Binary distribution: Unlike other editors, the convention for VS Code extensions that rely on a binary is to bundle the executable within the .vsix file. This is because several reason:
- The Microsoft marketplace holds do not restrict the package size of extension, and it's accessibility in certain country and regions is better than Github.
- Downloading the binary during editor startup often hits the limitation of anonymous rate, which exert negative influence to user experience.
- VS Code allows user to pin extension versions. If the extension is not self-contained this may not work as expected. For example, I once had to pin
rust-analyzer to an older version because a newer release maxed out my CPU
-
Dictionary synchronization: The extension stores the user dictionary in ~/.config/codebook/. While this is great for cross-editor consistency, it bypasses VS Code's native settings sync feature, which many users rely on to sync their entire editor environment across devices.
-
VS Code compatibility: In commit 9b83dd9 , the engines.vscode was set to ^1.109.0. This will prevent users who is not using the latest VS Code from using this useful extension, which I guess was not original intention.
Proposed Solution
-
Code actions: I propose following CSpell's convention by adding quick commands to command palette. For example, we can register commands like "Add word to dictionary" in the LSP client, which simply trigger the corresponding command of LSP server. This does not require many changed on codebook-lsp itself.
-
Binary distribution: Since many other popular extension bundle binary files (such as ruff, rust-analyzer and Microsoft's cpp tools), I proposed packaging the codebook-lsp executable to VS Code extension and aligning their versions. This does not require major changes as they are currently share the same github repository. Besides, for user who has installed codebook-lsp globally, we can detect it and use global installed one previously.
-
Dictionary synchronization: Since CSpell Checker has provided a extension settings field cSpell.userWords in settings.json, it will be helpful to have a similar filed in the codebook extension and has a merge logic to combine editor settings with global settings fill. This would support syncing the dictionary across different devices while maintaining cross-editor consistency on a single device.
-
VS Code compatibility: Considering that VS Code has no massive changes recently (despite copilot), I suggest rolling back the engines.vscode to ^1.80.0. We should also pin @types/vscode to the same version, as it corresponds to the engine version. And just ignore it during update.
Alternative Solutions
No response
Examples
No response
Additional Context
These are quite a lot changes and may take some time to implement. As I have experience in VS Code extension development, I would love to contribute and submit PRs for these. Please let me know what you think!
Feature Description
Hello @blopker ,
First, thank you for creating codebook! As a VS Code user for years, I've used CSpell Checker as my first choice, but I grew tired of its insensible memory consumption (often 300~500MB for a single file). Finally, I found this project provides similar features but with less source consumption. I'm a big fan now and excited about its potential.
As for VS Code extension, it's clear that it is in a very early stage and has many aspects to improve. So I'm opening this issue to propose a series of enhancements that would align it more closely with VS Code's ecosystem conventions and improve the overall user experience. I understand some conventions are quite different from other editors, so some of them may be quite tricky to handle.
I believe these changes would make codebook even more attractive to VS Code users and help get the extension ready for publishing. I'm happy to discuss them and would be willing to contribute pull requests to implement them incrementally.
Use Case
Code actions: Although VS Code has great support for code actions of LSP, using them frequently (for operations like "Add word to dictionary") can introduce some friction.
Binary distribution: Unlike other editors, the convention for VS Code extensions that rely on a binary is to bundle the executable within the .vsix file. This is because several reason:
rust-analyzerto an older version because a newer release maxed out my CPUDictionary synchronization: The extension stores the user dictionary in
~/.config/codebook/. While this is great for cross-editor consistency, it bypasses VS Code's native settings sync feature, which many users rely on to sync their entire editor environment across devices.VS Code compatibility: In commit 9b83dd9 , the
engines.vscodewas set to^1.109.0. This will prevent users who is not using the latest VS Code from using this useful extension, which I guess was not original intention.Proposed Solution
Code actions: I propose following CSpell's convention by adding quick commands to command palette. For example, we can register commands like "Add word to dictionary" in the LSP client, which simply trigger the corresponding command of LSP server. This does not require many changed on
codebook-lspitself.Binary distribution: Since many other popular extension bundle binary files (such as ruff, rust-analyzer and Microsoft's cpp tools), I proposed packaging the
codebook-lspexecutable to VS Code extension and aligning their versions. This does not require major changes as they are currently share the same github repository. Besides, for user who has installedcodebook-lspglobally, we can detect it and use global installed one previously.Dictionary synchronization: Since CSpell Checker has provided a extension settings field
cSpell.userWordsinsettings.json, it will be helpful to have a similar filed in the codebook extension and has a merge logic to combine editor settings with global settings fill. This would support syncing the dictionary across different devices while maintaining cross-editor consistency on a single device.VS Code compatibility: Considering that VS Code has no massive changes recently (despite copilot), I suggest rolling back the
engines.vscodeto^1.80.0. We should also pin@types/vscodeto the same version, as it corresponds to the engine version. And just ignore it during update.Alternative Solutions
No response
Examples
No response
Additional Context
These are quite a lot changes and may take some time to implement. As I have experience in VS Code extension development, I would love to contribute and submit PRs for these. Please let me know what you think!