5 ms·
The history and endurance of vi is impressive. I never thought I would be using the same editor today that I started using in the mid 90s because it was more l3
by be_erik 4mo ago
The history and endurance of vi is impressive. I never thought I would be using the same editor today that I started using in the mid 90s because it was more l33t.
The comments about LLM contributed code seems like a specific axe to grind that otherwise detracts from a nice history lesson.
- rmunn 4mo agoI started learning vi around the same time, but in my case (since I was expecting to work on Unix systems for decades, which has proven true) it was "because it'll always be there." I.e. if you're SSHing into a server to fix a problem, it's possible that /usr/bin/emacs won't be there (perhaps the problem you're fixing is that /usr isn't mounting), but you can nearly always count on /bin/vi being available: if you can access the server at all, you will be able to access vi, so at least learn its basic keystrokes, our prof told us. That advice was not entirely accurate (sometimes vi is in /usr/bin/vi, for example), and the merging of /bin with /usr/bin has made it kind of a moot point. (EDIT to add: Though the fact that busybox includes a basic vi implementation has kind of un-mooted the point, actually). But I first started learning vi because I figured I would need it professionally, and when the modal-editing workflow "clicked" for me, I figured out that I had just learned the editor I would want to stick with for years. And although vim replaced vi and nvim replaced vim in my finger-macros, that has remained true to this day.
- sgtlaggy 4mo ago> if you're SSHing into a server to fix a problem, it's possible that /usr/bin/emacs won't be there You don't need emacs on a server. TRAMP is built-in and can open remote files in a local instance over SSH, SMB, FTP, ADB, or docker/podman.
- pmontra 4mo agoYes, I can use TRAMP but as I ssh to the server anyway to run commands, I'm editing the files with vi there. Furthermore I'm sure I don't inadvertently edit the local version of the file instead of the remote one, or that I forget to kill the buffer with the remote file and edit it instead of the local one after a few days. What's on the server stays on the server.
- rmunn 4mo agoNever really learned emacs so didn't know TRAMP existed. When was it created? I was given that advice ("vi will always be available on the server") in the late 90's so I'm curious to know if TRAMP was an option my prof didn't know about (or didn't mention), or whether it was developed later and the advice was good at the time. EDIT: Found http://www.fifi.org/doc/tramp/tramp-emacs.html http://www.fifi.org/doc/tramp/tramp-emacs.html which mentions that TRAMP started development in November 1998. I would have been getting that advice in late 1997 or early 1998, given when I started my Unix class at college. So the answer appears to be that the advice was actually correct at the time, but superseded sooner than I thought it was.
- scbrg 4mo agoWell, TRAMP was preceded by ange-ftp, which let you edit files remotely over ftp. I was using that in 1995, and I didn't get the impression then that it was brand new, so it had probably been around for a while already. Of course, if your problem is "/usr won't mount", then it's likely that the ftp server isn't running either, so the advice still makes sense.
- owl57 4mo agoI often use vim despite knowing only a few basic commands because I'm already running various commands on the remote machine in the terminal and don't want the context switch. And because connection / file path completion in TRAMP is annoyingly slow if the server is far enough. As an extreme example, today I needed to combine parts of two files into one and decided that cat foo bar > foobar && mv foobar bar && vim bar of all things will better keep me in the flow than either googling how to insert one file into another in vim or starting up TRAMP.
- Scarbutt 4mo agoThe comments about LLM contributed code seems like a specific axe to grind that otherwise detracts from a nice history lesson. Seems like an interesting fact for those who don't follow the development of vim/neovim.
- normie3000 4mo ago> The comments about LLM contributed code seems like a specific axe to grind that otherwise detracts from a nice history lesson. The existence of vim classic would be hard to explain without reference to LLMs.
- berkes 4mo agoyes, but that could've been part of the explanation in vim-classic. Other attributes and reasons for improving/forking are explained in the entry of the fork.
- ethagnawl 4mo agoThe inclusion of comments about LLM generated code don't bother me and will probably be quite revealing (for better or worse) when people read this post in the future. Also, I have not been following the d2d development of vim closely after Bram's passing but I can't help but wonder what he'd have thought about this approach to development of vim.
- NewsaHackO 4mo agoYes, it almost feels like inserting politics to an otherwise apolitical discussion. Just unnecessarily charges the discussion and makes one not want to engage with the article.
- throawayonthe 4mo agoyou keep using that word, 'apolitical', i do not think it means what you think it means
- NewsaHackO 4mo agoI only used it once.
- ghost-of-dmr 4mo agoIf you were to sweep it under the rug, then it wouldn't be a history lesson, now would it?