feat: tab support for indentation stripping

[magistau]

Motivation

Many users prefer using hard tabs for indentation, but the existing indentation stripping logic only considers spaces as indentation characters and therefore doesn't strip any tab characters.

Context

Closes #7834.

Previously, stripIndentation would look for the longest common space-consisting line prefix; now it finds either the longest common space-consisting or tab-consisting prefix. A tab after a space is not considered as indentation, neither is a space after a tab.

[tomberek]

First consideration is if this changes historical evaluation values.

[edolstra]

See #2911, where the conclusion was that we cannot make this incompatible change without some kind of language versioning mechanism.

[magistau]

See #2911, where the conclusion was that we cannot make this incompatible change without some kind of language versioning mechanism.

This change is unlikely to break anything, as it only changes how tab-indented files get parsed. More precisely, for an indented string to be affected, every line of text in it must start with a tab and there must be no additional indentation, for example:

''
<tab>something
<tab>something else
<tab>something again
''

The following, however, is not affected by the change:

''
  <tab>something
  <tab>something else
  <tab>something again
''

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2024-02-28-nix-team-meeting-129/40499/1

[fricklerhandwerk]

I gather from #7834 that the actual issue is subtle behavior happening silently, therefore the change mainly needs an (opt-out) warning or error on mixed indentation to reduce opportunities for problems rather than introducing more of them.

Also this needs a release note and documentation in the manual, as this would be a substantial change.

[L-as]

Is there any good argument for why language versioning should be more than a nix-language-version setting along with an attribute in flakes to set it? Flakes are already experimental and don't need an RFC to be changed, and the nix-language-version setting could be guarded behind an experimental feature too.

[fricklerhandwerk]

@L-as that discussion happened on NixOS/rfcs#137. I suggest opening inline comments if you have questions, or, if what you want to add is more on the meta level, continue on the Discourse thread. Please read the RFC text first though, where we collected a wealth of arguments for and against certain approaches. I'd appreciate additions if you find that something is missing.

To summarise: Evolving the language is Hard(tm) given the notions of backwards compatibility guarantees being discussed, as can be observed in this very thread. But we have no agreed-upon stance, not even a clearly delineated group of people with authority to make such a decision. And even if we had the decisionmakers and decisions, we also have a resource and prioritisation problem to solve in order to implement those decisions.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2024-03-11-nix-team-meeting-132/42960/1

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/satisfaction-survey-from-the-new-rfc-166-formatting/49758/37

[Gergorius]

New user here.

I just ran into this problem and, looking at this discussion I am not seeing the light at the end of the tunnel.

What could be considered is to make the breaking change, but add a way to import nix files in a backwards compatible way. Something like an alternative import function. It could be called legacyImport (and legacyScopedImport). This function should take a nix version as the first argument to allow supporting more expression breaking bugfixes in the future and modify the scope of the imported nix file so it's import and scopedImport calls inherit the compatibility.

The sooner this is fixed the better because few things justify it bugging people for 6 more years, if not longer.