bin/59983: "expandtab" behaves counter-intuitively (and different from vim)

["thorpej%me.com@localhost via gnats" <gnats-admin%NetBSD.org@localhost>]

>Number:         59983
>Category:       bin
>Synopsis:       "expandtab" behaves counter-intuitively (and different from vim)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Sun Feb 08 16:15:01 +0000 2026
>Originator:     Jason Thorpe
>Release:        NetBSD 10.99.10 (but 11 is the same)
>Organization:
Formatting Fanatics Anonymous
>Environment:
NetBSD the-ripe-vessel 10.99.10 NetBSD 10.99.10 (GENERIC) #68: Fri Nov 17 14:40:27 PST 2023  thorpej@the-ripe-vessel:/space/src/sys/arch/amd64/compile/GENERIC amd64
>Description:
"expandtab" is documented as:

       expandtab, et [off]
              Prevent the use of <tab> characters in leading whitespace when
              shifting text, autoindenting, indenting with <control-T>, or
              outdenting with <control-D>.

This is different behavior from vim, for which <control-I> (i.e. <tab>) also applies.  As you know, vim is shipped as the "vi" on a pretty large number of systems, thus making NetBSD's behavior in this regard an outlier.

I think the documented behavior is counter-intuitive and "correct" only in the sense that it matches the documentation.  It leads to inconsistent indenting within a source file because <tab> is an easy (and natural) character to type, whereas <control-T> is not.  Furthermore, the setting is called "expandtab" and the key on the keyboard labeled "TAB" does not get the "expand" treatment.
>How-To-Repeat:
Edit a file.  Set "ts=2", "et", and "ai".  Create a line with a leading <tab> character and some text.  Hit return and let the editor auto-indent the next line and type some additional text.  Now, set "ts=8" and observe.

  oink
  snort

        oink
  snort

>Fix:
Yes please!