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

The vi family

lpar.ath0.com

Post reply on HN
Print view View original

71–80 of 198 posts

Re: The vi family

#71

Post by _torsk_ »

pippoit wrote: post #58

The first work i had to use vi and screen on a terminal, it were in 90s . I was used to dos editors ( edit, turbo C ... ) and windows . It was a pain. copy and paste at first was a nightmare. Copy from one file to another ,with named register and # was an hell ( it was vi not vim so only 2 files a time ,the actual edited and the prior ones ). I hated that place, that work, those tool for a while . I got so used to vi…

I actually learned VI using DOS and the Watcom C/C++ compiler and 32 bit dos extender, as it included a vi clone.

Maybe it should be included in the list. It can still be downloaded from the openwatcom project, https://openwatcom.org/ftp/manuals/1.5/vi.pdf

Re: The vi family

#72

Post by scbrg »

rmunn wrote: post #18
sgtlaggy wrote: post #12

Earlier quoted context omitted.

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

Never 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 which mentions that TRAMP start…

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

Re: The vi family

#73

Post by owl57 »

sgtlaggy wrote: post #12
rmunn wrote: post #7

Earlier quoted context omitted.

I 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…

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

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

Re: The vi family

#74

Post by elch »

isolli wrote: post #64
pjmlp wrote: post #61

> If you’re wondering why so many people would choose to use a fifty year old text editor with a notoriously steep initial learning curve, it’s because once you learn it, you can be ruthlessly efficient with your editing. I have learned it back in Xenix heyday, and decided I was better off with Emacs. Unfortunely not every server has Emacs pre-installed. On my own devenv I would rather reach out to IDEs, that replica…

I, for one, am happy that every terminal I've ever used still supports Emacs shortcuts. Useful, for instance, to cut a whole line and paste it later on (ctrl+k, ctrl+y).

Those are not terminal shortcuts. They are program shortcuts. E.g. bash supports Emacs command line editing shortcuts using GNU Readline library. But the library (and bash) support vi mode editing too. POSIX sh(1) specifies vi-mode command line editing only.

Re: The vi family

#75

Post by arethuza »

I learned vi in '86 or so mid way through the CS course I did. Later on I used emacs and various other editors for many years. The weird thing is that the basic vi commands are hardwired in my brain - I could happily edit a file in vi but I'd be stuck if I had to use emacs (even though I actually used emacs for far longer)...

Re: The vi family

#76

Post by keybored »

yanis_t wrote: post #26

It’s funny how many forks aiming to keep it free from LLM-generated code. The luddites are present even in the most progressive parts of the population.

I think you are wrong. Luddites don’t seem to exist any more, at least not on this board. Luddites had the courage to smash machines. People on this board might have complaints about LLM but then they will say well what can I do, protesting these developments is not on the Story Board.

Of course this is a total digression.

Re: The vi family

#77

Post by avadodin »

ventana wrote: post #9

One thing I noticed that with Claude Code and Codex running in the terminal, I tend to use VS Code much less than before, and found myself opening files in vim more often. It just looks like, for me, the agent development brings me back to using the basic tools, like many years ago, before VS Code existed.

Funny, because the only reason I fire up VSCode is to chat up the bots because we are AI-compliant now and the customers pay for it.

I tried nvim integration but it was half-baked and I can't even use nvim as an editor because they removed cscope support. nvi back in the day also dropped support for cscope because it wasn't vi enough. Hell, there is barely a working source repository for it. Only vim supports it out of the box. Am I the only person using cscope in 2026?

As of current day, I only use vim with no plugins to edit source code.

Re: The vi family

#78

Post by rockland »

applfanboysbgon wrote: post #39
nineteen999 wrote: post #15

I consider my vi/vim skills to be extremely minimalist subset, and probably horribly inefficient, since they were developed to work accross a broad range of UNIX systems (SCO, Solaris, HP-UX, OSF, AIX) and I rarely add anything to my vim configs on top of that other than syntax highlighting. But I'd still rather use it than just about any other text editor, just for the simplicity of that muscle memory alone. I have…

> I have way more stuff to keep in my head than I have room for and I can't afford to expend more than about 0.0001% of context on a text editor. I can't say I agree. To me this is equivalent to saying "I have way more music in my head than I have room for and I can't afford to expend more than about 0.0001% of context on a piano". The tool you use for 8+ hours a day is extremely important and even small gains will p…

To continue the musical instrument analogy, I already master the piano and I am happy with it solving my requirements. Learning the guitar will be a great undertaking, and provide me no new songs to play.

Hence, I will stick to my piano.

Re: The vi family

#79

Post by rswail »

I first used ed(1) back in the ye olden days of early 1980s, vi was like a major advance.

Came in handy when I had to talk a guy through updating a Solaris config file to allow the box to boot when he only had a serial console in the early 2000s.

Re: The vi family

#80

Post by strenholme »

This list is very useful; Vile isn’t quite Vi, but it’s close enough, and it includes a Windows32 binary which works with CP-1252 [1] (albeit in a separate window), and fits in under 700k (7-zip compressed).

What I wish existed was a fork of Busybox Vi which fully supports UTF-8. I’ve looked at the code and it would require a considerable rewrite to make it UTF-8 compatible, so I can see why it hasn’t been done.

[1] https://en.wikipedia.org/wiki/Windows-1252

Post reply on HN