Discussing two "holy war" topics at the same time
Cutting to the chase: text editors *and* tabs vs. spaces! Ooooh!
I have Macs in my life. They regularly receive updates. Over the past couple of days, they got Monterey version 12.3. This has seemed largely uneventful... until I went to edit something using my little wrapper script.
I've had this thing called "e" for a while now. It's a stupid little script which serves to do a couple of things. It starts my editor with a given file, and it kicks it with the right arguments to make it disable line wrapping and to make the [TAB] key actually put in two spaces.
Why have a script and not a .nanorc? Well, I think this pre-dates them having that file. Also, there is one nuance: I used to work on Makefiles a lot, like before I did my no-Makefile C++ build tool, and in that context, you *actually want* no-joke ^I tab characters. That's the only separator it'll allow when you write the subsequent parts of a rule.
So, my dumb script would use "-w -E -T 2" most of the time, except when it was running on a Makefile, at which point it would skip those args. Simple enough, right?
I've been using this script on Linux boxes and Macs alike for a long time, and it just broke on the Macs. I now get a complaint about "E" and "T" not being valid arguments, and then it spits out "possible starting arguments for pico editor". Wait, what?
pico is back? Yes indeed, on Macs, as of 12.3, pico is in fact back. To make sure I wasn't imagining things, I tracked down a machine that hadn't been upgraded yet and checked there. Sure enough, it was in fact nano and not pico.
macOS before 12.3 had pico as a symlink pointing to nano.
macOS 12.3 has nano as a symlink... pointing to pico!
For those not in this world, pico was the composer part of the pine mail client split off into its own thing. It had some weird licensing issues for years, and generally wasn't the easiest thing to find. Perhaps due to that, nano was started. It used to be pretty close in terms of features and behaviors, but nano diverged at some point. It picked up the ability to turn the [TAB] key into some number of spaces as if you whacked the space bar that many times. pico did not.
At some point, I switched from literal tab characters in my source code to blobs of spaces, probably due to using that style at work and not hating it. So, somewhere along the line I actually started depending on nano behavior without realizing it.
The macOS 12.3 update silently switched the base system from nano 2.0.6 to pico 5.09, and so if you use those switches, you're out of luck. My advice if you care about this kind of thing is to go get nano from Macports or whatever and forget about using the stock editor. That's what I'm going to do. At least I don't have to reprogram my fingers since "e foo" is still "e foo", no matter what it ends up calling underneath.
As for the lack of a feature in pico itself, it's kind of strange, really. If you go digging into the source, they have this random.c with a function called tab which claims to "simulate tab stop" using spaces. That said, I can't find any place where it would be called with the magic values which would make it behave that way.
This is also old-school C that goes back into the '80s and I don't feel much like spending too much time on it, so there might be some way.
It wouldn't surprise me if this switch is just more of Apple removing GPLed things from their OS - pico seems to use the Apache license. They dumped bash for zsh (MIT license) at some point (Big Sur, I think), and now this? Okay then.