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

[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 https://github.com/NixOS/rfcs/pull/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