"We"? Are you one of the core contributors of Fish? Otherwise I don't see why you'd argue in their place. According to the issue they seem perfectly fine with taking the maintenance burden of any patches to support older hardware, and they are even assisting the issue author to troubleshoot, so not sure what the problem is here?
You never know when some customer will put you in front of a vt220 and ask you to solve some arcane issue, and I sure am happy that at least some people care about helping others even if they don't have that specific hardware themselves.
> "We"? Are you one of the core contributors of Fish? Otherwise I don't see why you'd argue in their place.
It's not about arguing in their place. It's about thinking where our collective (includes the mentioned developers, me, and you as well) wants to take its technology. What afffects you, affects me and vice versa. We're not as seperate as you make out.
I’ve been in the field for 25 years, including work inside telco COs and large data centers, and as far as I know I’ve never been in the same room as a VT220. I doubt that many of my more junior coworkers have even heard of one.
I know what they are and how you might still use one today, but they’re extremely rare outside maybe a couple of very narrow niches.
When I was in college in the mid 90's, VT220's were still common on some parts of campus. A few years later, I had a job at a mostly DEC shop. They had a few terminals here and there, connected to Alpha Servers and a couple of old VAXes.
I haven't seen one in the wild in a little over 20 years...
That’s certainly possible, but if so it wasn’t something I had personal contact with enough to register that it happened. And I definitely knew what those terminals were, so I’m pretty certain I would have noticed that “oh, hey! A real VT220!”
I appreciate your comment, although I'm honestly surprised that fish maintainers are willing to put any effort into this, considering that fish is a "modern" shell which doesn't take backwards compatibility very seriously and isn't afraid of breaking with the traditional way of doing shell stuff.
Thanks! I don't know if I agree with your "doesn't take backwards compatibility very seriously" point specifically, although they do indeed try to refresh the shell UX a bit. Specifically from their design document[0], there is no mentions of backwards compatibility (except in connection to configurations), but they do mention that one of the goals is to follow posix syntax as much as possible, so seems they do have some care about backwards compatibility.
And lastly, "breaking with the traditional way of doing shell stuff" doesn't necessarily mean "doesn't work on old hardware", just means that the shell UX will/can be different, but similar.
> which doesn't take backwards compatibility very seriously
I go out of my way to make sure fish still compiles on ancient versions of operating systems (with the most recent compiler you can get on them) and still remains functional in the kernel console (no X), and others on the team go to even further extremes. We’ve argued for weeks over changing the names of variables that might break older fish scripts, even though fish isn’t really a non-interactive scripting language.
I think it is due to personal nostalgia and technical curiosity. Solving these kind of issues are more of a hobby contrasted to real work that needs to be done on project. Thus sparking more joy and engagement.
You never know when some customer will put you in front of a vt220 and ask you to solve some arcane issue, and I sure am happy that at least some people care about helping others even if they don't have that specific hardware themselves.