Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for local language configuration #1249

Merged
merged 8 commits into from
Apr 18, 2022

Conversation

kirawi
Copy link
Member

@kirawi kirawi commented Dec 11, 2021

Resolves #1217, allowing users to have configuration for local directories. It defaults to looking for every .helix folder until it finds a .git folder or is at the root, and merges all the configs in order.

@kirawi kirawi marked this pull request as draft December 11, 2021 00:19
helix-term/src/application.rs Outdated Show resolved Hide resolved
@kirawi kirawi force-pushed the local branch 4 times, most recently from e5eefae to d34a7d9 Compare December 11, 2021 02:45
@kirawi kirawi changed the title Add support for project-specific language configuration Add support for per-project language configuration Dec 11, 2021
helix-core/src/lib.rs Outdated Show resolved Hide resolved
@kirawi kirawi force-pushed the local branch 2 times, most recently from 390792c to c5682a0 Compare December 11, 2021 17:03
@kirawi kirawi marked this pull request as ready for review December 11, 2021 18:26
helix-core/src/lib.rs Outdated Show resolved Hide resolved
helix-term/src/main.rs Outdated Show resolved Hide resolved
helix-term/src/application.rs Outdated Show resolved Hide resolved
@kirawi
Copy link
Member Author

kirawi commented Dec 19, 2021

Tested and seems to work.

helix-core/src/lib.rs Outdated Show resolved Hide resolved
helix-term/src/application.rs Outdated Show resolved Hide resolved
@elferherrera
Copy link

elferherrera commented Apr 16, 2022

It works for me. I added a new languages.toml file in a .helix folder and it loaded that config. What I dont understand from the PR is if it will override all of one language settings or just sections of it.

Also, could it be discussed to have a window to show LSP loaded parameters?

@the-mikedavis
Copy link
Member

The merging behavior is on a per-key basis: if you want to turn LSP auto-format off for rust for example, you can have a languages.toml that says

[[language]]
name = "rust"
auto-format = false

And that will override that key but not change other keys like comment-token.

@kirawi
Copy link
Member Author

kirawi commented Apr 17, 2022

I tested on:

a
├───.git
├───.helix
└───b
    ├───.helix
    └───c
        └───.helix

With:

a/.helix/languages.toml

[[language]]
name = "rust"
auto-format = false
comment-token = "//"
indent = { tab-width = 4, unit = "    " }

b/.helix/languages.toml

[[language]]
name = "rust"
comment-token = "#"
indent = { tab-width = 4, unit = "    " }

c/.helix/languages.toml

[[language]]
name = "rust"
indent = { tab-width = 2, unit = "  " }

correctly becoming

[[language]]
auto-format = false
comment-token = "#"
file-types = ["rs", "rs"]
injection-regex = "rust"
name = "rust"
roots = ["Cargo.toml", "Cargo.lock", "Cargo.toml", "Cargo.lock"]
scope = "source.rust"

[language.indent]
tab-width = 2
unit = "  "

@elferherrera
Copy link

@kirawi how did you check the final result?

@kirawi
Copy link
Member Author

kirawi commented Apr 17, 2022

@elferherrera
Copy link

I see. I thought there was an option I didn't know

@archseer archseer merged commit c2a40d9 into helix-editor:master Apr 18, 2022
@@ -56,15 +56,33 @@ pub struct Application {
}

impl Application {
pub fn new(args: Args, config: Config) -> Result<Self, Error> {
pub fn new(args: Args) -> Result<Self, Error> {
Copy link
Member

@dead10ck dead10ck Apr 23, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm sorry I'm kind of late to the party here. Thanks for the change, @kirawi, this will be super useful!

But this particular part of the change actually presents a problem. I'm working on an integration testing branch, and this change makes it so that you can't pass in a pre-parsed Config object. This was very useful for testing, as it's super easy to just make the struct literal you want to describe the config option you want to test. Now it seems that the config can only come from a toml file. Could we please move this logic back into main?

This was referenced Apr 25, 2022
rbino added a commit to rbino/helix that referenced this pull request Sep 21, 2022
The documentation of find_root described the following priority for
detecting a project root:
- Top-most folder containing a root marker in current git repository
- Git repository root if no marker detected
- Top-most folder containing a root marker if not git repository detected
- Current working directory as fallback
The commit contained in helix-editor#1249
extracted and changed the implementation of find_root in find_root_impl,
actually reversing its result order (since that is the order that made
sense for the local configuration merge, from innermost to outermost
ancestors).

Since the two uses of find_root_impl have different requirements (and
it's not a matter of reversing the order of results since, e.g., the top
repository dir should be used by find_root only if there's not marker in
other dirs), this PR splits the two implementations in two different
specialized functions.

In doing so, find_root_impl is removed and the implementation is moved
back in find_root, moving it closer to the documented behaviour thus
making it easier to verify it's actually correct
rbino added a commit to rbino/helix that referenced this pull request Sep 21, 2022
The documentation of find_root described the following priority for
detecting a project root:
- Top-most folder containing a root marker in current git repository
- Git repository root if no marker detected
- Top-most folder containing a root marker if not git repository detected
- Current working directory as fallback

The commit contained in helix-editor#1249
extracted and changed the implementation of find_root in find_root_impl,
actually reversing its result order (since that is the order that made
sense for the local configuration merge, from innermost to outermost
ancestors).

Since the two uses of find_root_impl have different requirements (and
it's not a matter of reversing the order of results since, e.g., the top
repository dir should be used by find_root only if there's not marker in
other dirs), this PR splits the two implementations in two different
specialized functions.

In doing so, find_root_impl is removed and the implementation is moved
back in find_root, moving it closer to the documented behaviour thus
making it easier to verify it's actually correct
rbino added a commit to rbino/helix that referenced this pull request Sep 22, 2022
The documentation of find_root described the following priority for
detecting a project root:
- Top-most folder containing a root marker in current git repository
- Git repository root if no marker detected
- Top-most folder containing a root marker if not git repository detected
- Current working directory as fallback

The commit contained in helix-editor#1249
extracted and changed the implementation of find_root in find_root_impl,
actually reversing its result order (since that is the order that made
sense for the local configuration merge, from innermost to outermost
ancestors).

Since the two uses of find_root_impl have different requirements (and
it's not a matter of reversing the order of results since, e.g., the top
repository dir should be used by find_root only if there's not marker in
other dirs), this PR splits the two implementations in two different
specialized functions.

In doing so, find_root_impl is removed and the implementation is moved
back in find_root, moving it closer to the documented behaviour thus
making it easier to verify it's actually correct
rbino added a commit to rbino/helix that referenced this pull request Sep 22, 2022
The documentation of find_root described the following priority for
detecting a project root:
- Top-most folder containing a root marker in current git repository
- Git repository root if no marker detected
- Top-most folder containing a root marker if not git repository detected
- Current working directory as fallback

The commit contained in helix-editor#1249
extracted and changed the implementation of find_root in find_root_impl,
actually reversing its result order (since that is the order that made
sense for the local configuration merge, from innermost to outermost
ancestors).

Since the two uses of find_root_impl have different requirements (and
it's not a matter of reversing the order of results since, e.g., the top
repository dir should be used by find_root only if there's not marker in
other dirs), this PR splits the two implementations in two different
specialized functions.

In doing so, find_root_impl is removed and the implementation is moved
back in find_root, moving it closer to the documented behaviour thus
making it easier to verify it's actually correct
rbino added a commit to rbino/helix that referenced this pull request Sep 22, 2022
The documentation of find_root described the following priority for
detecting a project root:
- Top-most folder containing a root marker in current git repository
- Git repository root if no marker detected
- Top-most folder containing a root marker if not git repository detected
- Current working directory as fallback

The commit contained in helix-editor#1249
extracted and changed the implementation of find_root in find_root_impl,
actually reversing its result order (since that is the order that made
sense for the local configuration merge, from innermost to outermost
ancestors).

Since the two uses of find_root_impl have different requirements (and
it's not a matter of reversing the order of results since, e.g., the top
repository dir should be used by find_root only if there's not marker in
other dirs), this PR splits the two implementations in two different
specialized functions.

In doing so, find_root_impl is removed and the implementation is moved
back in find_root, moving it closer to the documented behaviour thus
making it easier to verify it's actually correct
archseer pushed a commit that referenced this pull request Sep 23, 2022
…3929)

* Split helix_core::find_root and helix_loader::find_local_config_dirs

The documentation of find_root described the following priority for
detecting a project root:
- Top-most folder containing a root marker in current git repository
- Git repository root if no marker detected
- Top-most folder containing a root marker if not git repository detected
- Current working directory as fallback

The commit contained in #1249
extracted and changed the implementation of find_root in find_root_impl,
actually reversing its result order (since that is the order that made
sense for the local configuration merge, from innermost to outermost
ancestors).

Since the two uses of find_root_impl have different requirements (and
it's not a matter of reversing the order of results since, e.g., the top
repository dir should be used by find_root only if there's not marker in
other dirs), this PR splits the two implementations in two different
specialized functions.

In doing so, find_root_impl is removed and the implementation is moved
back in find_root, moving it closer to the documented behaviour thus
making it easier to verify it's actually correct

* helix-core: remove Option from find_root return type

It always returns some result, so Option is not needed
herkhinah pushed a commit to herkhinah/helix that referenced this pull request Dec 11, 2022
…elix-editor#3929)

* Split helix_core::find_root and helix_loader::find_local_config_dirs

The documentation of find_root described the following priority for
detecting a project root:
- Top-most folder containing a root marker in current git repository
- Git repository root if no marker detected
- Top-most folder containing a root marker if not git repository detected
- Current working directory as fallback

The commit contained in helix-editor#1249
extracted and changed the implementation of find_root in find_root_impl,
actually reversing its result order (since that is the order that made
sense for the local configuration merge, from innermost to outermost
ancestors).

Since the two uses of find_root_impl have different requirements (and
it's not a matter of reversing the order of results since, e.g., the top
repository dir should be used by find_root only if there's not marker in
other dirs), this PR splits the two implementations in two different
specialized functions.

In doing so, find_root_impl is removed and the implementation is moved
back in find_root, moving it closer to the documented behaviour thus
making it easier to verify it's actually correct

* helix-core: remove Option from find_root return type

It always returns some result, so Option is not needed
@davidchisnall
Copy link

[ Sorry for commenting here, but you appear not to have set up the security tab for reporting potential vulnerabilities ]

If I add a .helix folder in my git repo that sets the language server protocol command to rm -rf ~ then won't a Helix user that opens a file inside a clone of my git repo end up deleting their entire home directory? Most other systems that have similar behaviour have some mitigation such as allowing only commands from an allow list to run or requiring the user to inspect and authorise the config file every time that it changes. I didn't see anything here.

@kirawi
Copy link
Member Author

kirawi commented May 27, 2023

This isn't the appropriate place to make that comment. You should create a separate issue instead.

@davidchisnall
Copy link

If you do not configure the security settings on GitHub or provide a SECURITY.me, external people have no idea how to report suspected security issues. There was no coordinated disclosure process documented for this project, so I filed it on the place closest to where the problem was introduced. If you want security issues filed in a specific place then I suggest that you document this. Either way, I have reported it and it’s now up to you to choose how to handle it.

@pascalkuthe
Copy link
Member

I dont think editors have a particular high thread model that would warrant a security policy like that. If you clone untrusted code and run any language server on it you are already vulnerable (rust analyzer runs cargo check which runs build scripts which can run arbitrary untrusted code, same for many other LS) so really any editor that runs language servers is gulernabke. So emacs-lsp mode, nvim and kakune can all be attacked if you open files from a compromised repo.

Either way just like any other problem it should be reported as an issue instead of a random comment on old PR that is likely easily forgotten.

@archseer
Copy link
Member

I'm currently working on a patch to explicitly approve each new workspace.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Local configuration folder