Skip to content

Per Language Indent Config#1304

Draft
mewoocat wants to merge 8 commits into
NotAShelf:mainfrom
mewoocat:main
Draft

Per Language Indent Config#1304
mewoocat wants to merge 8 commits into
NotAShelf:mainfrom
mewoocat:main

Conversation

@mewoocat

Copy link
Copy Markdown

Sanity Checking

  • I have updated the changelog as per my changes
  • I have tested, and self-reviewed my code
  • My changes fit guidelines found in hacking nvf
  • Style and consistency
    • I ran Alejandra to format my code (nix fmt)
    • My code conforms to the editorconfig configuration of the project
    • My changes are consistent with the rest of the codebase
  • If new changes are particularly complex:
    • My code includes comments in particularly complex areas
    • I have added a section in the manual
    • (For breaking changes) I have included a migration guide
  • Package(s) built:
    • .#nix (default package)
    • .#maximal
    • .#docs-html (manual, must build)
    • .#docs-linkcheck (optional, please build if adding links)
  • Tested on platform(s)
    • x86_64-linux
    • aarch64-linux
    • x86_64-darwin
    • aarch64-darwin

Add a 👍 reaction to pull requests you find important.

@github-actions

github-actions Bot commented Dec 22, 2025

Copy link
Copy Markdown

🚀 Live preview deployed from c7fe3c1

View it here:

Debug Information

Triggered by: mewoocat

HEAD at: main

Reruns: 1864

github-actions Bot pushed a commit that referenced this pull request Dec 23, 2025

@horriblename horriblename left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

I don't think these kinds of options are needed, vim typically provides a good default for most filetypes so it feels weird providing the same default for most filetypes. If you feel like vim's default is not good, consider making a PR upstream.

If the goal is a more convenient per-filetype option API, there are better ways to do so, e.g. mimicking the vim.options API, but for each filetype.

Comment thread lib/languages.nix Outdated
Comment thread lib/languages.nix Outdated
@mewoocat

mewoocat commented Dec 24, 2025

Copy link
Copy Markdown
Author

@horriblename

I don't think these kinds of options are needed, vim typically provides a good default for most filetypes so it feels weird providing the same default for most filetypes. If you feel like vim's default is not good, consider making a PR upstream.

oh I wasn't aware vim had any per filetype defaults, I'm not really finding much info on this. I had always thought the tab configuration was static.

If the goal is a more convenient per-filetype option API, there are better ways to do so, e.g. mimicking the vim.options API, but for each filetype.

I'm not sure I follow. Are you suggesting something like vim.options.<filetype>.indentSize as opposed to what I have now vim.languages.<lang>.indentSize?

github-actions Bot pushed a commit that referenced this pull request Dec 24, 2025
github-actions Bot pushed a commit that referenced this pull request Dec 24, 2025
@horriblename

Copy link
Copy Markdown
Collaborator

I'm not sure I follow. Are you suggesting something like vim.options..indentSize as opposed to what I have now vim.languages..indentSize?

something like vim.perFileTypeOptions.<lang>.shiftwidth

though I'd ask for opinions from @NotAShelf and @Soliprem first

@NotAShelf

Copy link
Copy Markdown
Owner

I'm not sure I follow. Are you suggesting something like vim.options..indentSize as opposed to what I have now vim.languages..indentSize?

something like vim.perFileTypeOptions.<lang>.shiftwidth

though I'd ask for opinions from @NotAShelf and @Soliprem first

I'm not sure honestly. Adding yet another namespace under vim just to handle options per-file seems... ugly. What I had mind recently was an abstraction to write what is essentially Neovim's ftplugin files in the runtime directory, and perhaps we could abstract around that. That said, I'm pretty happy to keep it under vim.languages since that is our current language abstraction. Though, there needs to be a toggle which is off by default. We do not want to set defaults for people.

P.S.: rather than this:

          function()
            vim.bo.tabstop = ${toString indentSize}
            vim.bo.softtabstop = ${toString indentSize}
            vim.bo.shiftwidth = ${toString indentSize}
          end

we'll want each option to be customizable separately.

P.P.S: Allow nulling the values to avoid setting the option altogether. If cfg.tabstop is null, it should not be set and so on.

github-actions Bot pushed a commit that referenced this pull request Jan 13, 2026
@mewoocat

Copy link
Copy Markdown
Author

@NotAShelf what do you think about these changes?

github-actions Bot pushed a commit that referenced this pull request Jan 13, 2026
@snoweuph

Copy link
Copy Markdown
Collaborator

I personally see little reason for this, as .editorconfig exists, neovim will respect it: https://neovim.io/doc/user/plugins/#_builtin-plugin%3a-editorconfig

Yes, this is per-project config, not global config, but at the point where you share your projects with others, you prolly will need to add one anyways

@mewoocat

mewoocat commented Mar 29, 2026

Copy link
Copy Markdown
Author

I personally see little reason for this, as .editorconfig exists, neovim will respect it: https://neovim.io/doc/user/plugins/#_builtin-plugin%3a-editorconfig

Yes, this is per-project config, not global config, but at the point where you share your projects with others, you prolly will need to add one anyways

I agree, I originally was going into this without much knowledge of .editorconfig. But now Im more aware, I don't think my changes here are worth it.

@NotAShelf

Copy link
Copy Markdown
Owner

I'm in favor of keeping this change. .editorconfig is not properly standardized, and I don't see a reason to enforce it just because it exists.

@mewoocat

Copy link
Copy Markdown
Author

I'm in favor of keeping this change. .editorconfig is not properly standardized, and I don't see a reason to enforce it just because it exists.

Wdym not properly standardized?

@NotAShelf

Copy link
Copy Markdown
Owner

Not all LSPs or formatters support it. An autocmd for setting the indent, however, will always work.

@mewoocat

Copy link
Copy Markdown
Author

Well if you're cool with current implementation here I'll try to publish the PR sometime in the near future.

@snoweuph

Copy link
Copy Markdown
Collaborator

Not all LSPs or formatters support it.

some don't support it, because the language standardized the indentations, like go and make.

But yes, there are LSPs out there, that don't support the protocol, or act as IF (im talking about you tombi the AI slop)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants