Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

Allow setting indent globally #3159

Closed
scgtrp opened this issue Jul 22, 2022 · 9 comments · May be fixed by #6652
Closed

Allow setting indent globally #3159

scgtrp opened this issue Jul 22, 2022 · 9 comments · May be fixed by #6652
Labels
A-helix-term Area: Helix term improvements C-enhancement Category: Improvements

Comments

@scgtrp
Copy link
Contributor

scgtrp commented Jul 22, 2022

I currently have an incredibly long ~/.config/helix/languages.toml, to which I append a copy of this for every language I use or encounter:

[[language]]
name = "..."
indent = { tab-width = 4, unit = "\t" }
auto-pairs = false

I discovered while writing this that I don't actually have to set auto-pairs = false in each language anymore (I don't think the global one existed/worked when I started using Helix?), so that's neat, thanks!

I would like to be able to do the same for indent. The desired behavior is that I can say "always indent with tabs, for any file type", and spaces are only used if I open an existing file that is already indented with spaces.

Potential issue with this: Some languages (e.g. makefiles) require a particular type of indentation as part of their syntax. These languages should probably have some sort of "no, really, use this even if the user said something else" flag in their indent configuration, to avoid emitting broken makefiles when the user has set space-indentation globally. Alternatively, the language-level indent could be split into indent and default-indent, where the order of precedence is language.indent > global.indent > language.default-indent.

@scgtrp scgtrp added the C-enhancement Category: Improvements label Jul 22, 2022
@kirawi kirawi added the A-helix-term Area: Helix term improvements label Jul 23, 2022
@sploders101
Copy link

I would like to second this. I'm currently doing the exact same thing, and am still worried I run the risk of starting to use a new language that automatically starts using spaces for indentation without me noticing.

Not trying to get into the tabs vs spaces debate (just adding my objective reasoning for this need), but my personal opinion is that someone's personal indentation width preference should not be forced on everyone else. I have a lot of trouble reading 2-space indentation, so I like to render at 4, and tabs let me do that, so as a courtesy to others, I use tabs so they can view my code however they like. However, in today's development world, devs (or at least I) use so many languages on a day-to-day basis it's hard to keep track, and I'd love a global setting with language-specific override for languages with intolerant syntax (for example, Home Assistant's YAML parser really seems to hate tabs, so I should be able to override for YAML).

I may be willing to help with this in my spare time if someone could point me to the relevant parts of the project.

@pbrkr
Copy link

pbrkr commented Dec 6, 2022

I think this is a key feature for users working on projects which have a strict coding style and use multiple programming languages.

Also note that simply enumerating indent overrides for all languages which helix currently knows about is not a one-off solution. This list would also have to be updated if new languages are added to Helix's default languages.toml file.

@dead10ck
Copy link
Member

dead10ck commented Dec 7, 2022

I'm actually personally against having a global setting for tab width. Each language has its own style, and I don't agree with the mindset of just ignoring idiomatic conventions. Just as one shouldn't write snake case in Java, or camel case in Rust, one shouldn't use an unconventional tab width.

Also, it's likely that if you really insisted on doing this, you're probably not talking about more than half a dozen languages, max. It's not like you'd notice some Prolog dialect was added and have to go add another entry.

@scgtrp
Copy link
Contributor Author

scgtrp commented Dec 7, 2022

I don't actually use Helix anymore (and will probably unsubscribe from this ticket), but as of when I stopped, I had 11: C++, C, Rust, JavaScript, TypeScript, HTML, YAML, Python, CSS, Markdown, and Bash. For the sort of personal use I was using it for, consistency with my own opinions was far more important than consistency with the opinions of some style guide.

The nice thing about optional settings is that you don't have to set them if they don't suit you :)

@linkert
Copy link

linkert commented Feb 1, 2023

I understand that I'm not the target audience as I'm pretty much a normie who enjoys tinkering with my computer, a non-dev, mostly janky scripts, configs and markdown documents. But I would also like some way of telling Helix: unless told otherwise a tab consists of spaces, two spaces to be exact.

@lucyColeclough
Copy link

I'm actually personally against having a global setting for tab width. Each language has its own style, and I don't agree with the mindset of just ignoring idiomatic conventions. Just as one shouldn't write snake case in Java, or camel case in Rust, one shouldn't use an unconventional tab width.

Also, it's likely that if you really insisted on doing this, you're probably not talking about more than half a dozen languages, max. It's not like you'd notice some Prolog dialect was added and have to go add another entry.

My issue is that I don't want to write a config for every language.
If you're one who enjoys spaces then it wouldnt be as obvious of a problem.

@lucyColeclough
Copy link

in regards to #6652
I propose the notion that a global indent option would override any default configuration in helix
Then any option specified in the user~s languages.toml would then override this global option
This prevents the need to specify something like indent.required= true for each language, as it is assumed that if a user specifies a language in languages.toml, that it should override the global default
Perhaps behaviour for whether non specified fields should inherit from the global setting or the helix default
This could be a per language setting, either inherit from global or helix defaults, that way it would work with languages with no custom fields in languages.toml

If going with that, then to increase reuse whilst resolving the issue posed in the openning comment of this thread, perhaps languages which are dependent on a specific indentation can have their inheritance set to the helix default, by default as opposed to the user specified global setting.

I do not have the time to change this my self and it is not an issue that would be desirable for me to see develop into a halt in existing work.

@Lilith-In-Starlight
Copy link

i think global options should override the default languages.toml and the global languages.toml, meaning they are only overriddeo by the languages.toml present in a project directory

This means that you can have

  • Your customized global default
  • Your customized edge cases for certain languages
  • Your customized edge cases for certain projects

Which I think is an ideal amount of control

@Rudxain
Copy link
Contributor

Rudxain commented Mar 25, 2024

@dead10ck

Each language has its own style, and I don't agree with the mindset of just ignoring idiomatic conventions.

That's why formatters and linters are a thing 🙃. And that's why the global setting should be just a default, overriden by whatever indent.unit is detected in a file or languages.toml.

Just as one shouldn't write snake case in Java, or camel case in Rust, one shouldn't use an unconventional tab width.

Rust's clippy warns when using non-idiomatic naming-conventions. I would expect other linters (maybe even "intrusive" formatters) would go as far as to rename all symbols on "auto-fix"

@helix-editor helix-editor locked and limited conversation to collaborators Apr 12, 2024
@pascalkuthe pascalkuthe converted this issue into discussion #10363 Apr 12, 2024

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
A-helix-term Area: Helix term improvements C-enhancement Category: Improvements
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants