Add editorconfig support

[BuonOmo]

Closes #8534

Release Notes:

• Added EditorConfig support, overriding .zed/settings.json when a .editorconfig file is present

---

This is a first POC of editorconfig support. The main consideration to go further IMHO is: can we also store these settings as we do for settings per-language. This would likely be much more efficient. It might also require a more drastic change (maybe re-coding the ec4rs lib to use zed's filesystem), hence I wanted to already publish this for faster feedback by anyone interested in working along. As of now my goal was to make the minimal amount of changes possible

Tests could also be improved to cover every options.

[SomeoneToIgnore]

Looks nice, I think that will cover most of the .editorconfig demand and is quite small.

Besides the comments left, there are two important things I'd love to see in this PR:

• instead of changing existing tests extensively, a new test for all properties overridden in .editorconfig, to ensure we are able to apply "all" of them, and, maybe in the same test, an external fs edit scenario, to ensure Zed is able to update its state accordingly

• a file watching, as you've noted in your comment

[BuonOmo]

@SomeoneToIgnore I'm lacking some Cow knowledge. Could you help me with these failing tests ?

By the way, I'm off next week. I'll be back on that PR the 26 or 27.

[SomeoneToIgnore]

I am also quite occupied during this and next weeks, so great that we can postpone it — no rush, let's try again later.

[BuonOmo]

I wanted to use:

Suggested change

	let fs = FakeFs::new(cx.executor());
	fs.insert_tree_from_real_fs(path, path).await;
	let project = Project::test(fs, [path], cx).await;
	let project = Project::test(Arc::new(RealFs::default()), [path], cx).await;

But somehow the .zed/settings file is not detected that way... Anyone knows what I am missing ?

[BuonOmo]

I think that besides perf, this is ready to ship. Should I focus on perf now (including file watching then) or shall we ship (once approved ofc!) and see this in another PR?

[SomeoneToIgnore]

I have left more comments and generally disagree that we have to ship soon: for now, it's not working correctly yet and the perf issue seems relatively straightforward to fix.

I have already mentioned that we should add the file watching and I do not see why not — left a more elaborate comment in the related thread.

[SomeoneToIgnore]

I went on and implemented the main bits, but spoiled the tests.
I see some odd access patterns of the whole thing when debugging, so will spend some time on fixing related things.

One confusing thing I've noticed is that [*.md]-like globs were ignored by the library(?): https://github.com/rust-lang/rust-analyzer/blob/095926ea6f008477a15a2ec6b0b8797e2e5be0e5/.editorconfig#L13
It would be interesting to know what's wrong with this.

[SomeoneToIgnore]

Ok, I've found a right place to put all new editorconfig data and fixed all issues.

The PR is getting ready, I have a concern left:

• multiplayer support

Current code would not work with the remote workflow, as there's no real files and no FS scans on the client side, neither ec4rs::properties_of with its recursive FS ascend will work.

Seems that we have to actually copy the ConfigFiles::open code and resolve the configs manually.
After everything's resolved, we'll push a similar to UpdateWorktreeSettings request from the host to clients, for them to populate their parsed editorconfig values.

• WASM api seems to be using new extension data incorrectly: https://github.com/zed-industries/zed/pull/16349/files#diff-406f3ebd5f5aad8ecc4d8daf3e321b1d62b73848145a3f94f5b08a92f9c0dff5R402-R406
• overall, AllLanguageSettings::language is very hot, being called multiple times per second — the new code is adding some performance penalty on top, we need to think a bit more on ways to improve that and need to profile the code better

[BuonOmo]

Back! Thank you for taking the time to implement, I feel a bit overwhelmed by your dev as I'm quite new to the Rust ecosystem. But if I can still help let me know!

Current code would not work with the remote workflow, as there's no real files and no FS scans on the client side, neither ec4rs::properties_of with its recursive FS ascend will work.

Then we could re-implement that method using zed's fs, couldn't we?

[SomeoneToIgnore]

It's harder than that, I'm afraid, as someone has to notify about things to the clients (FS has no way to know about real file changes and when to poll for them).

I can handle this PR from now on, if that's fine with you — the main, impact part is done thanks to you and now it's just some Rusty and Zed'y details I have to deal with.
It might take some time though, as LanguageSettings is quite a foundational thing in our codebase and there's another task I have to tackle first.

[dbarnett]

someone has to notify about things to the clients

How is that handled for .zed/settings.json files?

[SomeoneToIgnore]

This question would receive a different answer in August and today, as the part of code related to the whole settings sync is refactored actively due to ssh remoting.

So far, it landed into

zed/crates/project/src/project_settings.rs

Line 202 in 6d4ecac

pub struct SettingsObserver {

and most probably stays this way, but I'd wait more before ssh remoting project finishes before ingraining anything .editorconfig-related as there could be more bugfixes and refactorings on top of the existing functionality.

So let me describe a general approach to the PR that would have been merged if submitted, on the example of settings.json processing and answer the question along the way.

---

The main idea is to watch files (in "offline" Zed locally on the host, in ssh and via-centralized-server (collab) Zed on the client) and gather updates into its memory.
Directly on remote or through ssh client/collab server, eventually all that new/update data is supposed to land into

zed/crates/settings/src/settings_store.rs

Lines 161 to 175 in 6d4ecac

	pub struct SettingsStore {
	setting_values: HashMap<TypeId, Box<dyn AnySettingValue>>,
	raw_default_settings: serde_json::Value,
	raw_user_settings: serde_json::Value,
	raw_extension_settings: serde_json::Value,
	raw_local_settings: BTreeMap<(WorktreeId, Arc<Path>), serde_json::Value>,
	tab_size_callback: Option<(
	TypeId,
	Box<dyn Fn(&dyn Any) -> Option<usize> + Send + Sync + 'static>,
	)>,
	_setting_file_updates: Task<()>,
	setting_file_updates_tx: mpsc::UnboundedSender<
	Box<dyn FnOnce(AsyncAppContext) -> LocalBoxFuture<'static, Result<()>>>,
	>,
	}

then user's Zed will call

zed/crates/settings/src/settings_store.rs

Line 683 in 6d4ecac

fn recompute_values(

to parse and sync the resolved settings into its memory, and merge them in the end, in a generic fashion.

The language generic part is located in

zed/crates/language/src/language_settings.rs

Line 879 in 6d4ecac

impl settings::Settings for AllLanguageSettings {

We have to repeat a somewhat similar path for .editorconfig files:

• on top, by reacting to file changes and storing the metadata bits similar to raw_local_settings from one the snippets above
  Per path, we'll have to honor .editorconfig data split by file, but otherwise seems to be the same "read the file into string" as with our json config.

This also means checking all remote workflows' sync events, to ensure we get that passed over to the client with the "real" editor.

• then we'd need to merge those via recompute_values instead of recursive fs searches this PR does now, and keep in mind globs and root = true stop action, using the same stack-based approach recompute_values has for settings value recompute

• last but not least, improve the bits I've added to get the language settings: https://github.com/zed-industries/zed/pull/16349/files#diff-9940b9338a85c5c6646ce6a8d2b3b7798845cbff70ec415d8df4c82d370efef2R800
  and check that extensions pass the right path there, and Zed is able to

• have I mentioned tests (there are 2 files named editor_tests.rs, one for "offline", another for "remote" tests, and we have to edit both.
  Ideally, we have to check that settings synchronized after external, possibly remote, editor changes, when one or multiple users edit random .editorconfig configs (in multiplayer tests) and language related (and not) files (verifying correctness in in singplayer tests)

• more manual tests

[BuonOmo]

@SomeoneToIgnore this seems really fun to do. I'd like to be part of it if possible :)

[SomeoneToIgnore]

Why not, as this research PR is simpler to close than modify anyway at this state.

A change to track file changes and store raw file data for singleplayer & multiplayer modes could be made into a nice standalone PR.

[SomeoneToIgnore]

#18616 altered a protocol and server DB level to support editorconfig sync messages.
So now we can do another .ends_width similar to

zed/crates/project/src/project_settings.rs

Lines 401 to 419 in 9cd4242

	if path.ends_with(local_settings_file_relative_path()) {
	let settings_dir = Arc::from(
	path.ancestors()
	.nth(local_settings_file_relative_path().components().count())
	.unwrap(),
	);
	let fs = fs.clone();
	settings_contents.push(async move {
	(
	settings_dir,
	LocalSettingsKind::Settings,
	if removed {
	None
	} else {
	Some(async move { fs.load(&abs_path).await }.await)
	},
	)
	});
	}

to update the raw settings storage.

[SomeoneToIgnore]

@BuonOmo
can you check out https://github.com/zed-industries/zed/compare/kb/editorconfig?expand=1 branch?
PR: #19455
It lacks to be multiplayer test, but otherwise seems to be ready when I was testing it.

[BuonOmo]

@SomeoneToIgnore you were faster than me ! I think overall LGTM and you also already added some multiplayer test. I'd like to review a bit more the file crates/settings/src/settings_store.rs which is a bit hard to grasps to me. And I'll do some local test. All of this on Sunday afternoon and/or Tuesday :)