4 ms·
I do not believe that is possible without compromising the goals of one of the two projects. Vim is expected to continue to work everywhere, even on some bank'
by 3eb7988a1663 2y ago
I do not believe that is possible without compromising the goals of one of the two projects.
Vim is expected to continue to work everywhere, even on some bank's circa 1980 mainframe. NeoVIM has become an effort to revitalize the project. Support for ancient systems was tossed almost immediately (eg no more 8.3 filename support code). NeoVIM also included some much improved default configuration values.
- dleeftink 2y ago> even on some bank's circa 1980 mainframe Continuity I get, but how much are we collectively burdened by having a few ancient uses determine the wants of the many?
- Out_of_Characte 2y agoOur window of compatibility only seems to grow larger over time. Old systems mostly get replaced when they lose function or the replacement becomes cheaper. But the replacement usually expects to last slightly longer than what its replacing. We've seen this slowly creep up in home computers, phones and even servers. I would argue that this is a function of small incremental improvements in everything from hard drives to computing. Lots of designs from the past can no longer connect to the internet in a meaningfull capacity but new hardware today might meaningfully last far longer than the developers could even anticipate.
- kstrauser 2y agoI wonder about that, too. Not that anyone's beating my door down to port my own projects to zOS or anything, but I consider modern Linux/BSD to be my baseline target for all new code I write. If it runs well on amd64/aarch64 Linux, Mac, and {Free,Open}BSD, that's enough. Well, and Windows, if someone makes it run there and it's not onerous to support. I wouldn't accept patches that make it harder to build or maintain on those primary systems. It's not that I actively hate anything that isn't a recent 64-bit Unix, but that the people on other systems are either 1) hobbyists who are competent to port stuff to their own systems, or 2) companies who aren't paying me for extraordinary support. Bummer if something I wrote last week doesn't run on HP-UX, but it's not going to cost me sleep.
- jnwatson 2y agoI had to think long and hard about whether to accept a PR that fixed ppcle64 support on the library I maintain. Since it wasn't too much of a diff, I accepted it, but in many other situations I wouldn't.
- kstrauser 2y agoIf it’s trivial with zero adverse affects on common hardware, fine. If it adds the equivalent of a bunch of ifdefs or requires adding autoconf, nah.
- joseda-hg 2y agoAt this point, between WSL2 and how good wine has gotten, there's a lot of crossover for building/maintaining, outside the target OS
- diggan 2y ago> Continuity I get, but how much are we collectively burdened by having a few ancient uses determine the wants of the many? Because of neovim and the power of forking, essentially nothing. The ones who favor stability choose one program, the ones who favor bleeding-edge chooses another that matches.
- kps 2y agoVim is also POSIX-compliant (or very close, with compatibility options, on a POSIX platform). Neovim doesn't have that goal.
- Ferret7446 2y agoIf you want POSIX compliant, better to install a proper vi. Normal Vim is extremely not POSIX compliant, and I wager 100.00% (rounded to the significant digits) of Vim users don't know, use, or want POSIX compliance. You lose a lot of features you would consider to be basic. Also you probably want ed (the standard text editor) for POSIX compliance. (Fun fact, vi is not required by POSIX, so you will not find it on every single POSIX compliant host.)