Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Understanding the Origins and the Evolution of Vi and Vim

pikuma.com

Post reply on HN
Print view View original

101–110 of 128 posts

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

#101

Post by sudahtigabulan »

kps wrote: post #99
montroser wrote: post #23

So interesting to see how the ADM-3A keyboard layout itself was such a fundamental influence for ESC and hjkl movement in vi.

And that I suspect originates with ASCII Control-H = backspace (cursor left), Control-J = line feed (cursor down). Control-K and Control-L don't match but weren't so important that they couldn't be repurposed by an early display terminal.

Yep. It's all in the manual.

https://archive.org/details/ADM-3A-User-Reference-Manual-Apr...

(This page, and Figure 1-3 below).

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

#102

Post by _fat_santa »

qsort wrote: 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 :)

I would say it’s incredible to see the quality and “durability” of Linux/Unix tools. The other day I wondered “how old is grep”, looked it up and realized that I use a piece of software that’s over 50 years old on a daily basis.

The fact that these tools have stood the extreme test of time is really something.

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

#103

Post by neitsab »

gustavopezzi wrote: post #64
ngcc_hk wrote: post #2

I was surprised to see this on pikuma… I guess “ Also... Emacs sucks! ” is ok to end the blog entry. To me it is just hard to use 2-3 figures and it seemed hard for inventory as well. That sucks.

Author here! I remember struggling with the decision of adding that last sentence or not. But at the end I was sure most readers would get that it is obviously a joke. Maybe a bad one but still a joke.

I read it as sincere, gratuitous and unfounded mud-slinging, which made me end this remarkable article on a pretty underwhelming note. We all have different senses of humor, mine would have needed some caption here :'-)

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

#104

Post by tasuki »

arbitrandomuser wrote: post #57
sudahtigabulan wrote: post #45

Earlier quoted context omitted.

> 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.

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

It's just an extra key press. And you can choose which visual mode you'd like!

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

#105

Post by chongli »

homebrewer wrote: post #93
Izkata wrote: post #67

Earlier quoted context omitted.

I don't think it's even so much about keystroke count as it is the "commands" are more like a language that you can keep getting better in. For example, from above: > d), d{ That's not two different commands, it's one action (delete) and two different motions (forwards one sentence, backwards one paragraph). Motions work on their own for moving the cursor, but can be combined with different actions and repetitions to…

And these commands are useless for programming unless you format source code in a very specific way, adding white space such that everything is split into "paragraphs" that can be thought of and operated on as a single unit. As someone down below mentioned, programming is not as much editing text as it is massaging the underlying AST. Proper IDEs (not VSCode) in a hands of a power user who knows what his "hammer" can…

As someone down below mentioned, programming is not as much editing text as it is massaging the underlying AST. Proper IDEs (not VSCode) in a hands of a power user who knows what his "hammer" can do (and how to invoke the necessary behaviour) are much more efficient at it compared to any text editor.

That's assuming you're spending all day editing files written in the language(s) supported by your IDE. That assumes a great deal about your programming environment, toolchain, plugins, and configuration. Switch to a different language with different syntax, different idiomatic style, different IDE plugins, and you may be faced with a totally different editing paradigm.

This is where vi shines: the tool is excellent at editing text and is therefore 100% language-agnostic. It can easily handle jumping between files written in different languages, including plaintext files, configuration files, domain-specific language files, and otherwise many other files with syntax that may not be supported by your favourite IDE. Furthermore, it is equally happy working on files that combine different sections written in different languages. Sure, some other editors (such as emacs) and IDEs (such as RStudio) also support this sort of editing, but vi doesn't need any special support for it.

This philosophy, of making text the first-class citizen, in many ways mirrors the Unix philosophy. It also happens to be the case that vi (as well as its ex command line) provides a very convenient command for piping lines, paragraphs, and any other motion you desire through a shell command (or pipeline) of your choosing. This makes it very easy to format text using commands such as `fmt` or `column`, or apply line-numbers using `nl`. This, I believe, makes vi the ideal text editor for developers working on Unix or Linux software.

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

#107

Post by nyarlathotep_ »

pugworthy wrote: post #18
qsort wrote: 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 :)

I have used VI for many, many years and honestly use perhaps 25% at best of its abilities. But still I get comments about how fast and smoothly I can use it from other developers. Which I think speaks to how powerful even the basic editor can be. And yes, you can also take my VIM plugin (for Visual Studio) from my cold dead hands.

> And yes, you can also take my VIM plugin (for Visual Studio) from my cold dead hands.

First thing I install on any IDE/Editor.

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

#108

Post by tcoff91 »

skydhash wrote: post #94
tcoff91 wrote: post #53

Earlier quoted context omitted.

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.

I think Vim and Neovim is better suited as editors, meaning quick launch, fast localization of files and fast editing actions. And I like plugins that support this philosophy. But the goals with emacs is to be a complete platform for anything plain text (with a bit of extra widgets). Almost whatever you need the terminal for can be replicated there, and they will share some common convention. Mail, file manager, musi…

Yes Emacs is still a better platform for building applications on for sure. Emacs lisp is a better language than Lua although harder to learn.

I used Emacs with evil mode for years until switching to neovim last year. It was really great.

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

#110

Post by sodapopcan »

Buttons840 wrote: post #76
sodapopcan wrote: post #11

Earlier quoted context omitted.

If you follow any discussions around development, it seems the chance of this happening is essentially zero. I feel that they will continue to diverge into completely different editors.

What do you predict the pros/cons of Vim vs Neovim will be?

Hard to say, but as it stands, but my view is that that the typical nvim users want Vim as a full-fledged IDE with little effort whereas Vim users still want Vim largely as a text editor. And of course there are already a whole bunch of incompatible differences between them that would only be noticed by the more "power" users I suppose.
Post reply on HN