Live data from Hacker News

Understanding the Origins and the Evolution of Vi and Vim

pikuma.com

51–60 of 128 posts

Re: Understanding the Origins and the Evolution of Vi and Vim

#51
post #17

I was slightly surprised that they didn't add a mention of neovim.

And vis editor, that also has herietage from sam.

I actually use vis daily, alongside NeoVim - for opening very large files.

Most editors choke at couple MB, Vis can open 10 Gigabyte text files with zero delay.

Re: Understanding the Origins and the Evolution of Vi and Vim

#52
post #22

Aside from neovim, no mention of nvi, Keith Bostic's fork which was BSD mainline, and the Japanese hacked on to add utf handling. The main divergence of note is tab expansion.

And one probably wouldn’t notice, but the buffer is backed by a “recno”[0] Berkeley DB instance[1].

[0] https://edoras.sdsu.edu/doc/BerkeleyDB/ref/am_conf/logrec.ht...

[1] https://en.wikipedia.org/wiki/Berkeley_DB

Re: Understanding the Origins and the Evolution of Vi and Vim

#53
post #26

Earlier quoted context omitted.

Same here. Tbh, you're comment just inspired to do a deep dive on VI. Wonder how much more productivity I can squeeze out if I spend an weekend focused on it.

The productivity comes from not having to think about your editing while simultaneously realizing that you can do some complex editing really easily. I use Emacs and Vim both (I prefer Emacs) and It's quite nice when you can streamline some quick code edits. My latest experience with Vim was helping a friend fixing some import with a React Native project. A quick grep on one terminal (I could have used quickfix) and…

Now with neovim I feel like the plugin ecosystem is catching up to Emacs. Lua has unlocked the potential.

Typescript dev ex in neovim is light years ahead of what I achieved in Emacs. Neovim’s lsp integration is better than Emacs imo. Blink.cmp is so fast.

Magit is definitely far superior to anything in neovim though and so is org mode.

Re: Understanding the Origins and the Evolution of Vi and Vim

#54
post #6

It's incredible how good of a design Vi is. Try this experiment: Busybox includes a tiny clone of vi with a reduced feature set. It's very stripped down when compared to Vim or even other vi clones, but as a pure text editor it's still more powerful than most modern day IDEs . I love my Jetbrains IDEs, but you can take my Vim plugin from my cold dead hands :)

> It's incredible how good of a design Vi is. It's interesting how this design was forced into existence by the extremely limited hardware at the time: TFA>> It was really hard to do because you've got to remember that I was trying to make it usable over a 300 baud modem. That's also the reason you have all these funny commands. It just barely worked to use a screen editor over a modem. That's why we got commands lik…

That's a great point. On modern systems, there's a false economy where editor stunts are not going make most people a significantly faster programmer. (Although some ppl just like them, e.g thinking they are "more powerful".) But on a very slow terminal, these things really did make a huge difference.

Re: Understanding the Origins and the Evolution of Vi and Vim

#55

> The creator of MINIX, Andrew Tanenbaum, asked the community to choose between Stevie and Elvis to be adopted as the main text editor for their OS. Elvis was chosen and it's the default text editor on MINIX until today. Point of order: Minix switched to BSD nvi in 2013 https://github.com/Stichting-MINIX-Research-Foundation/minix... Not that it matters -- Minix itself hasn't had a commit since 2018 -- but the last fi…

Up to now I have been using elvis exclusively, rather than vim, both on Windows and Linux - I never saw the need to switch, since elvis does everything I need. I just retired it last month, when I upgraded some systems to the latest release of Debian Bookworm and the elvis graphic interface started crashing the whole X windows manager. I have the source code, but I don't have the patience to recompile and debug it.

Re: Understanding the Origins and the Evolution of Vi and Vim

#56
post #42

Earlier quoted context omitted.

I started with TECO (Text Editor Character Oriented) on Caltech's PDP-10 back in 1975. There were no glass ttys, just DECwriters and ASR-33s (ugh). I.e. TECO was a line editor. A couple years later, ADM-3A's arrived. And so did a TECO macro that turned TECO into a screen editor! Oh, what joy! Isn't it a amazing that a macro could turn a line editor into a screen editor? I also used TECO on my H-11 PDP-11 computer.

The name I recall from using it on a PDP 11/04 was 'Text Editor and Corrector' https://en.wikipedia.org/wiki/TECO_(text_editor) I vaguely recall it had a line-open / visual mode, like ex/vi, which we didn't use because we were on a dot-matrix line printer / teletype. The ADM-3A had the Ctrl key on the home line; this design made it easy for editors from that period (vi, emacs) to make heavy use of Ctrl. Thanks to tho…

It could also be invoked on VAX/VMS under the name “MUNG”, which was said to stand for “Modify Until No Good”. I think that style of invocation did something slightly different than using the TECO command, like creating a new file.

Re: Understanding the Origins and the Evolution of Vi and Vim

#57
post #6

It's incredible how good of a design Vi is. Try this experiment: Busybox includes a tiny clone of vi with a reduced feature set. It's very stripped down when compared to Vim or even other vi clones, but as a pure text editor it's still more powerful than most modern day IDEs . I love my Jetbrains IDEs, but you can take my Vim plugin from my cold dead hands :)

> It's incredible how good of a design Vi is. It's interesting how this design was forced into existence by the extremely limited hardware at the time: TFA>> It was really hard to do because you've got to remember that I was trying to make it usable over a 300 baud modem. That's also the reason you have all these funny commands. It just barely worked to use a screen editor over a modem. That's why we got commands lik…

This imo is a shortcoming of vim on modern systems, the action precedes the selection.

I would like to select first have a visual feedback of what I selected before taking action on it . Helix and kakuone have got this right .

I often find myself going to visual mode to emulate this.

Re: Understanding the Origins and the Evolution of Vi and Vim

#58
post #6

It's incredible how good of a design Vi is. Try this experiment: Busybox includes a tiny clone of vi with a reduced feature set. It's very stripped down when compared to Vim or even other vi clones, but as a pure text editor it's still more powerful than most modern day IDEs . I love my Jetbrains IDEs, but you can take my Vim plugin from my cold dead hands :)

What is the experiment?

Re: Understanding the Origins and the Evolution of Vi and Vim

#59

Earlier quoted context omitted.

I started with TECO (Text Editor Character Oriented) on Caltech's PDP-10 back in 1975. There were no glass ttys, just DECwriters and ASR-33s (ugh). I.e. TECO was a line editor. A couple years later, ADM-3A's arrived. And so did a TECO macro that turned TECO into a screen editor! Oh, what joy! Isn't it a amazing that a macro could turn a line editor into a screen editor? I also used TECO on my H-11 PDP-11 computer.

We had TECO on our DEC VAXes running VMS in the early-mid 1980s. It had a ”VT52” mode (as you say, a macro), and at least one of the terminals on my desk supported those escape sequences. Wikipedia says the VT52 terminal was made from 1975 to 1978, so those macros were probably fairly early. By this stage, TECO distribution was fragmented with various incompatible versions around, so probably some lacked that macro o…

Great story!

The TECO macro I posted is the VT52 one.

Re: Understanding the Origins and the Evolution of Vi and Vim

#60
My first text editor has been vi on NCR Unix machines back in 1986 and DEC Ultrix in 1988. I fell so deeply in love that I joyed only when I could get a "copy" of vi.exe from MKS unix-like toolkit for DOS. That file only.

Nice read, indeed. Especially the final sentence.

> Also... Emacs sucks!

Post reply on HN