Add support for custom file association settings

[ljwljwljwljw]

Release Notes:

• Added support for custom file associations.

This PR allows user to set their own file association settings.

Users can specify the association settings by configuring the .zed/settings.json:

{
  "associations" : {
    "Rust": ["my_rust", "my_rs"],
    "C++": ["hh"]
  }
}

I modified the language_for_file function to receive an additional context_info (a tuple of (worktree_id, &AppContext)) argument, and then use the AppContext to load user's custom association settings before using the default path_suffixes described in each language's config file to detect the language.

I don't know if this is a appropriate way to solve the problem, and I am encountering difficulties in obtaining AppContext in the following locations: [1], [2], [3]

so I left them unchanged, awaiting for your suggestions.

Related discussions:

• #5178
• #6108
• #7150

[cla-bot[bot]]

We require contributors to sign our Contributor License Agreement, and we don't have @ljwljwljwljw on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

[ljwljwljwljw]

@cla-bot check

[cla-bot[bot]]

The cla-bot has been summoned, and re-checked this pull request!

[SomeoneToIgnore]

Sorry, just noticed the

awaiting your suggestions part

I'm not sure what to suggest except "go up the stack and get the context from there". E.g. fn deserialize_symbol is called in two places that have cx: AsyncAppContext that could be turned into the &mut AppContext with cx.update(|cx| ...)

semantic_index is a harder case, because it uses background_executor to spawn off the tasks on a background thread — those do not have the context but above them, there's again a cx: AsyncAppContext which is Clone.

[ljwljwljwljw]

Thank you for your review! In addition to the issues you mentioned above, how do you think of moving the path_suffixes out from the LanguageConfig? This way, the LanguageConfig will only contain static language configurations. We can then create a dedicated struct to manage file associations, fully dynamically configured by settings.json. The current default path_suffixes can be relocated to default.json, making it easier for users to understand how to configure file associations. Moreover, we can use the dedicated struct to detect configuration conflicts and provide user feedback.

[ljwljwljwljw]

I found that a new data structure LanguageMatcher is now used in the main branch code: https://github.com/zed-industries/zed/blob/ed791c4fc1066c686c96db6f6f828c3e8742a841/crates/language/src/language.rs#L430-L442 It is used in many places and it makes separating path_suffixes from static language config more difficult. If I understand correctly, it is used to allow extensions to specify files that they can work with, and now there is a simple workaround to set custom file associations: write a new extension to set your own path_suffixes and first_line_pattern, but may the file associations of different extensions still conflict with each other?

Would it be better if extensions only specify an exact Language and the language detection is performed by a dedicate file association setting?

Because there are so many changes related to language config in past two weeks and it is far beyond my ability to complete this pull request, I will close the PR later.

[SomeoneToIgnore]

I'm afraid there's no good answer for that right now. I suspect that whatever the current stance is, it might change later as language extensions mature, so this PR is indeed a bit in the way of all this and might get closed for now: touching languages' code is a big endeavor and having multiple of those in parallel gets extra hard.