
Things this doesn't currently handle: - [x] ~testing~ - ~we really need an snapshot test that takes a vscode settings file with all options that we support, and verifies the zed settings file you get from importing it, both from an empty starting file or one with lots of conflicts. that way we can open said vscode settings file in vscode to ensure that those options all still exist in the future.~ - Discussed this, we don't think this will meaningfully protect us from future failures, and we will just do this as a manual validation step before merging this PR. Any imports that have meaningfully complex translation steps should still be tested. - [x] confirmation (right now it just clobbers your settings file silently) - it'd be really cool if we could show a diff multibuffer of your current settings with the result of the vscode import and let you pick "hunks" to keep, but that's probably too much effort for this feature, especially given that we expect most of the people using it to have an empty/barebones zed config when they run the import. - [x] ~UI in the "welcome" page~ - we're planning on redoing our welcome/walkthrough experience anyways, but in the meantime it'd be nice to conditionally show a button there if we see a user level vscode config - we'll add it to the UI when we land the new walkthrough experience, for now it'll be accessible through the action - [ ] project-specific settings - handling translation of `.vscode/settings.json` or `.code-workspace` settings to `.zed/settings.json` will come in a future PR, along with UI to prompt the user for those actions when opening a project with local vscode settings for the first time - [ ] extension settings - we probably want to do a best-effort pass of popular extensions like vim and git lens - it's also possible to look for installed/enabled extensions with `code --list-extensions`, but we'd have to maintain some sort of mapping of those to our settings and/or extensions - [ ] LSP settings - these are tricky without access to the json schemas for various language server extensions. we could probably manage to do translations for a couple popular languages and avoid solving it in the general case. - [ ] platform specific settings (`[macos].blah`) - this is blocked on #16392 which I'm hoping to address soon - [ ] language specific settings (`[rust].foo`) - totally doable, just haven't gotten to it yet ~We may want to put this behind some kind of flag and/or not land it until some of the above issues are addressed, given that we expect people to only run this importer once there's an incentive to get it right the first time. Maybe we land it alongside a keymap importer so you don't have to go through separate imports for those?~ We are gonna land this as-is, all these unchecked items at the bottom will be addressed in followup PRs, so maybe don't run the importer for now if you have a large and complex VsCode settings file you'd like to import. Release Notes: - Added a VSCode settings importer, available via a `zed::ImportVsCodeSettings` action --------- Co-authored-by: Mikayla Maki <mikayla@zed.dev> Co-authored-by: Kirill Bulatov <kirill@zed.dev> Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com> Co-authored-by: Marshall Bowers <git@maxdeviant.com>
88 lines
2.6 KiB
Rust
88 lines
2.6 KiB
Rust
use anyhow::Result;
|
|
use fs::Fs;
|
|
use serde_json::{Map, Value};
|
|
|
|
use std::sync::Arc;
|
|
|
|
pub struct VsCodeSettings {
|
|
content: Map<String, Value>,
|
|
}
|
|
|
|
impl VsCodeSettings {
|
|
pub fn from_str(content: &str) -> Result<Self> {
|
|
Ok(Self {
|
|
content: serde_json_lenient::from_str(content)?,
|
|
})
|
|
}
|
|
|
|
pub async fn load_user_settings(fs: Arc<dyn Fs>) -> Result<Self> {
|
|
let content = fs.load(paths::vscode_settings_file()).await?;
|
|
Ok(Self {
|
|
content: serde_json_lenient::from_str(&content)?,
|
|
})
|
|
}
|
|
|
|
pub fn read_value(&self, setting: &str) -> Option<&Value> {
|
|
if let Some(value) = self.content.get(setting) {
|
|
return Some(value);
|
|
}
|
|
// TODO: maybe check if it's in [platform] settings for current platform as a fallback
|
|
// TODO: deal with language specific settings
|
|
None
|
|
}
|
|
|
|
pub fn read_string(&self, setting: &str) -> Option<&str> {
|
|
self.read_value(setting).and_then(|v| v.as_str())
|
|
}
|
|
|
|
pub fn read_bool(&self, setting: &str) -> Option<bool> {
|
|
self.read_value(setting).and_then(|v| v.as_bool())
|
|
}
|
|
|
|
pub fn string_setting(&self, key: &str, setting: &mut Option<String>) {
|
|
if let Some(s) = self.content.get(key).and_then(Value::as_str) {
|
|
*setting = Some(s.to_owned())
|
|
}
|
|
}
|
|
|
|
pub fn bool_setting(&self, key: &str, setting: &mut Option<bool>) {
|
|
if let Some(s) = self.content.get(key).and_then(Value::as_bool) {
|
|
*setting = Some(s)
|
|
}
|
|
}
|
|
|
|
pub fn u32_setting(&self, key: &str, setting: &mut Option<u32>) {
|
|
if let Some(s) = self.content.get(key).and_then(Value::as_u64) {
|
|
*setting = Some(s as u32)
|
|
}
|
|
}
|
|
|
|
pub fn u64_setting(&self, key: &str, setting: &mut Option<u64>) {
|
|
if let Some(s) = self.content.get(key).and_then(Value::as_u64) {
|
|
*setting = Some(s)
|
|
}
|
|
}
|
|
|
|
pub fn usize_setting(&self, key: &str, setting: &mut Option<usize>) {
|
|
if let Some(s) = self.content.get(key).and_then(Value::as_u64) {
|
|
*setting = Some(s.try_into().unwrap())
|
|
}
|
|
}
|
|
|
|
pub fn f32_setting(&self, key: &str, setting: &mut Option<f32>) {
|
|
if let Some(s) = self.content.get(key).and_then(Value::as_f64) {
|
|
*setting = Some(s as f32)
|
|
}
|
|
}
|
|
|
|
pub fn enum_setting<T>(
|
|
&self,
|
|
key: &str,
|
|
setting: &mut Option<T>,
|
|
f: impl FnOnce(&str) -> Option<T>,
|
|
) {
|
|
if let Some(s) = self.content.get(key).and_then(Value::as_str).and_then(f) {
|
|
*setting = Some(s)
|
|
}
|
|
}
|
|
}
|