Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here we'd be parsing globs on each invokation of
language_for_file_internal
, which is a pretty hot function; I think a better option would be to change type ofuser_file_types
toOption<&HashMap<Arc<str>, Vec<Pattern>>>
(and the corresponding type in settings: https://github.com/zed-industries/zed/blob/main/crates/language/src/language_settings.rs#L57) and do the parsing in settings deserialization (https://github.com/zed-industries/zed/blob/main/crates/language/src/language_settings.rs#L566). That way, invalid globs will be rejected at settings load time, which should be better.Also, mea culpa but we already have a dependency for glob parsing (
globset
) - we can use that instead ofglob
as it should also be presumably more efficient for our use case (of multiple globs) with GlobSet. This is my fault, as I've suggested using glob initially. Sorry!Thus,
user_file_types
will beHashMap<Arc<str>, GlobSet>
in the end.Overall though this looks good to me; once we move glob parsing to Settings-load time, we should be good to merge :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I started refactor the code to accept
Option<&HashMap<Arc<str>, Vec<Pattern>>>
onAllLanguageSettings
but I faced some issues to add the Lifetime parameter (need a lot of refactors to add it), so I add the type offile_types
asOption<HashMap<Arc<str>, GlobSet>>
, treated it onimpl settings::Settings for AllLanguageSettings
method like this:With this I need get the reference on
zed/crates/language/src/language_registry.rs
Line 481 in 32e6424
user_file_types.file_types.as_ref()
and refactor thepath_matches_custom_suffix
to be something like:I'll push the changes, if have some appointments, how I said, I'm a newcomer and I little bit afraid to make some big changes on the code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, what you have done is pretty much fine; I didn't mean to use a reference type on the
AllLanguageSettings
itself, since - as you've pointed out - we'd have to carry that lifetime around everywhere, and that would be a pain in the bum.