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

111–120 of 128 posts

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

#111

Post by mikojan »

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.

Then why does your IDE not look like Scratch?

It is because nobody has found a better representation then text when it comes to editing concrete syntax trees.

Yes, you will rarely reach for d) or d} when editing Java or JavaScript. But the Vi paradigm does not stop at prose. And it does not stop at modern IDE capabilities either.

The Vi paradigm just enables people to do it faster. With less friction.

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

#112

Post by teo_zero »

amelius wrote: post #96

Does anyone know of a good Vim plugin for navigating Python code blocks? E.g. moving to the start/end of a block, or moving to the next block.

If I remember correctly the script runtime/ftplugin/python.vim remaps [[, [], ]], etc. to work with Python's idea of blocks.

Besides, the plugin michaeljsmith/vim-indent-object defines a new text object ("i"), based on indentation levels.

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

#113

Post by maccard »

jghn wrote: post #41
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 :)

It is worth knowing pure vi to some extent. To the point you raise, it's pretty much guaranteed to exist on any system you're on. That's not true of anything else, even vim

I can count on one hand the number of times I’ve had to use vi or nano and not had another option in 15 years programming. Optimising for that use case is not an efficient use of time.

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

#114

Post by doix »

chongli wrote: post #105
homebrewer wrote: post #93

Earlier quoted context omitted.

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…

Yeah, vim was invaluable when I worked in the semiconductor industry. Lots of perl, TCL, SKILL (a lisp dialect) and giant verilog netlists. Languages which don't really have proper IDEs or great all in one tooling.

Now I'm a webdev with everything written in typescript and just use Cursor (basically vscode) with the vim plugin. i miss the tab model from vim a lot, but apart from that the vim plugin is close enough.

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

#115

Post by alwillis »

davemp wrote: post #87
flomo wrote: post #54

Earlier quoted context omitted.

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.

I’m not sure. Command based editing opens more doors than just optimizing keystrokes. There are edits I somewhat regularly do with Vim macros that save me minutes of typing and cognitive burden of examining refactor locations. It’s probably not going to be make or break, but I do think it’s significant in a p > 0.05 sense. I imagine Vim is only just a local optima too. There are newer editors [0] that are more AST aw…

> There are newer editors [0] that are more AST aware…

With Neovim, you get the best of both worlds: it's Vim with AST support via Treesitter and LSP support baked in.

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

#116

Post by beezle »

bsenftner wrote: post #82

Harvard University used to teach an assembly language class back in the 80's, taught on a mainframe - a VAX 11/780 or similar I seem to recall. This was an open enrollment class, available to evening and summer students. That class was, well it as Assembly, so it was difficult. The homework assignments were odd, seemingly unrelated. At the midterm, the professor handed out a makefile that combined every assignment to…

minor: Vax 11/780 was a minicomputer, though DEC itself refered to it as a 'supermini"

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

#117

Post by beezle »

SulphurCrested wrote: post #50
WalterBright wrote: post #34

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…

A lot of the "elite" compsci students at my college in the early-ish 80s were still using TECO on our DECSYSTEM 2060 but some of the cool-kids were trying that new Emacs thing ;)

Me, being just a lowly compsci minor, prefered the full screen editor called FOXE. Was very simply to use and did the job fine for writing/editing programs of the length typical of homework assignments. Don't recall all the particulars to comment on search, replace, etc.

Unfortunately, there is like zero internet info on it beyond: "Little (if any) information is available for this visual editor available for TOPS-20 in the early 1980's. It was similar in appearance to the then new EMACS but had a far simpler command structure."

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

#118

Post by jghn »

maccard wrote: post #113
jghn wrote: post #41

Earlier quoted context omitted.

It is worth knowing pure vi to some extent. To the point you raise, it's pretty much guaranteed to exist on any system you're on. That's not true of anything else, even vim

I can count on one hand the number of times I’ve had to use vi or nano and not had another option in 15 years programming. Optimising for that use case is not an efficient use of time.

Same, except it goes back 30 years, but it sucks when that one time comes up. I'm not suggesting one becomes a wizard. I'm suggesting understanding basic commands.

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

#119

Post by wredcoll »

alwillis wrote: post #115
davemp wrote: post #87

Earlier quoted context omitted.

I’m not sure. Command based editing opens more doors than just optimizing keystrokes. There are edits I somewhat regularly do with Vim macros that save me minutes of typing and cognitive burden of examining refactor locations. It’s probably not going to be make or break, but I do think it’s significant in a p > 0.05 sense. I imagine Vim is only just a local optima too. There are newer editors [0] that are more AST aw…

> There are newer editors [0] that are more AST aware… With Neovim, you get the best of both worlds: it's Vim with AST support via Treesitter and LSP support baked in.

Any good recommendations for plugins to add commands to work on asts?

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

#120

Post by WuxiFingerHold »

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.

As someone who started modal editing with Helix and then moved to NeoVim (LazyVim):

After a very short transitioning period (a week or so), I don't have this issue anymore (at all). Keeping coming back to visual mode is probably counterproductive for your transition. So maybe you should stop doing this for some time. Then you'll hopefully find yourself using the visual mode rarely.

Post reply on HN