Live data from Hacker News

Bill Joy's greatest gift to man – the vi editor (2003)

theregister.co.uk

101–110 of 186 posts

Re: Bill Joy's greatest gift to man – the vi editor (2003)

#101
post #27

Earlier quoted context omitted.

What's the story with NeoVim exactly? I am trying it out on Linux because I got some recommendations that it's better than Vim, but I've run into some problems because for instance with setting up plugins and things, lots of times the documentation seems to be geared toward Vim, and sometimes I've gotten errors it's hard to figure out because of this. It kind of gives me the perception there just aren't that many peo…

Neovim definitely has significant market share, you can compare Github stars as one statistic to consider: https://github.com/vim/vim - 20k https://github.com/neovim/neovim - 36.5k This is in some part due to the fact that neovim has been on Github longer, but it's still a a major indicator. Neovim has many benefits over Vim, and has been applying pressure on Vim for years to improve its own development and codebase.…

> Neovim definitely has significant market share, you can compare Github stars as one statistic to consider:

I would not consider GH stars to be at all indicative of market share in this case. Vim is installed by default on so many distributions that people just use it and expect it to be there. I have been using vim for at least 15 years and I didn't even know its source was hosted on GH until seeing your post. NeoVim, on the other hand, is something that you have to know about and seek out, and in doing so it's pretty likely that you end up on its GH project page, making it more likely you'd star it.

Re: Bill Joy's greatest gift to man – the vi editor (2003)

#102
The first editor I used was pico, then nano. I joined a sysadmin team shortly after college and they said they would not install those tools on the Sun servers; I had to learn vi. I wasn't prepared to argue but I wanted to know why. They said you'll find vi on almost every system and it will work fine in almost any terminal. To me there was a lot of value in that, and once I did learn vi, I liked it for all of the other reasons folks are mentioning in this thread.

Re: Bill Joy's greatest gift to man – the vi editor (2003)

#103

Earlier quoted context omitted.

I used vi and vim for about 25 years before switching to Emacs. I did this because: 1 - I got deeply interested in Lisp and Scheme, and Emacs was reputed to have the best editing environment for these languages 2 - Almost all of Emacs itself and Emacs' entire package ecosystem is written in eLisp, which is a tremendous improvement over vimscript, in which almost all vim packages are written. I'd just rather read and…

> I used vi and vim for about 25 years before switching to Emacs. Then maybe you can help:) I've tried, multiple times, to switch to emacs. And every time, I get stuck, because vim keybindings are so wired in to my muscle memory now, and even the broader interactions are hard to adopt (i.e., I expect to get a command prompt by escaping to command mode and then typing ":", and then all commands are available). Is ther…

You must have heard of evil by now... but if not check it out. It's a vim emulation layer for Emacs.

Re: Bill Joy's greatest gift to man – the vi editor (2003)

#104
post #51
post #27

Earlier quoted context omitted.

What's the story with NeoVim exactly? I am trying it out on Linux because I got some recommendations that it's better than Vim, but I've run into some problems because for instance with setting up plugins and things, lots of times the documentation seems to be geared toward Vim, and sometimes I've gotten errors it's hard to figure out because of this. It kind of gives me the perception there just aren't that many peo…

NeoVim was started to add in a couple features that had gotten pushback from Bram when the original forker(?) (long since moved on from the project) got frustrated with getting shot down. Basically the relationship at this point between the two projects appears to be that the NeoVim team implements some features. The ones that gain significant traction, Bram then implements in his own style. At this point they are ba…

> One of the side effects of that is the NeoVim people like to brag how much code they've deleted from Vim. The thing they don't mention is all the deps they've added in the process.

You present this in a negative light, and perhaps it's misleading of them to not acknowledge the added dependencies, but this is exactly what I want maintainers of my workhorse software to do. I would much rather they delete their own code and replace it with well-tested, robust dependencies rather than maintaining their wheel reinventions.

(Of course, whether or not the chosen dependencies are well-tested and robust is the trick.)

Re: Bill Joy's greatest gift to man – the vi editor (2003)

#105

Earlier quoted context omitted.

I used vi and vim for about 25 years before switching to Emacs. I did this because: 1 - I got deeply interested in Lisp and Scheme, and Emacs was reputed to have the best editing environment for these languages 2 - Almost all of Emacs itself and Emacs' entire package ecosystem is written in eLisp, which is a tremendous improvement over vimscript, in which almost all vim packages are written. I'd just rather read and…

> I used vi and vim for about 25 years before switching to Emacs. Then maybe you can help:) I've tried, multiple times, to switch to emacs. And every time, I get stuck, because vim keybindings are so wired in to my muscle memory now, and even the broader interactions are hard to adopt (i.e., I expect to get a command prompt by escaping to command mode and then typing ":", and then all commands are available). Is ther…

I'd recommend using evil-mode. It'll give you the stock vim keystrokes and the command prompt (ie. what you get when you press the : key).

I was tempted to say "just use evil-mode", but it's really not "just" a matter of using it. evil-mode doesn't get you everything, as many Emacs modes just don't have vim-like bindings, and you'll either need to rebind them all yourself to something that makes sense for you (which is what I did, and I recommend creating lots of hydras to help you remember everything that's available), or you can use something like Spacemacs or Doom which will set up sane defaults for a lot of modes.

I've never used Spacemacs or Doom myself, but I've heard good things about both.. and bad things about Spacemacs, and how Doom is supposed to be an improvement on Spacemacs.. but as I've not used either I can't really comment on how accurate those claims are. I'd suggest doing your own research on those, or maybe someone here can comment on them.

Also, I'd recommend joining #evil-mode on the Frenode IRC network, the Emacs subreddit, and the Emacs StackExchange. You can get all of your questions answered there, and learn a ton about Emacs by reading these.

Re: Bill Joy's greatest gift to man – the vi editor (2003)

#107
post #98

For those who do not understand why people are fanatical about vi, here are some reasons: Vi is keyboard only. This means that actions with the mouse are optimized through the keyboard. There are "hotkeys" for most tasks you use with a mouse. Vi has the idea of objects. Words, lines and paragraphs are objects you can operate on. Vi defines a "language" for operating on objects. For instance, 'd' is delete. You can de…

"This is especially important if you have to edit a file on a remote server" This may have been true a decade ago, but editors like Visual studio code now have remote editing abilities over SSH. I regularly have 50+ files open at a time for editing/compiling and I've never found editors like VI very helpful. If I need to make a quick edit to a config file, it does the job.

I'd love to hear more about this. What VS Code plugin are you using to accomplish edits over SSH? I checked out Remote Development, but it is actively unable to function with the open-source version of VSCode:

https://github.com/VSCodium/vscodium/issues/240#issuecomment...

Re: Bill Joy's greatest gift to man – the vi editor (2003)

#108
post #98

For those who do not understand why people are fanatical about vi, here are some reasons: Vi is keyboard only. This means that actions with the mouse are optimized through the keyboard. There are "hotkeys" for most tasks you use with a mouse. Vi has the idea of objects. Words, lines and paragraphs are objects you can operate on. Vi defines a "language" for operating on objects. For instance, 'd' is delete. You can de…

"This is especially important if you have to edit a file on a remote server" This may have been true a decade ago, but editors like Visual studio code now have remote editing abilities over SSH. I regularly have 50+ files open at a time for editing/compiling and I've never found editors like VI very helpful. If I need to make a quick edit to a config file, it does the job.

Something that I always find lacking in these discussions is that the VIM evangelists never mention the way that I use vim: strictly as a keyboard-only editor plugin.

I tried using vim-only setups but there's so much configuring and weird things. Nothing to me has worked as great as my current VSCode + Vim plugin setup. It's the best of both worlds, as I get the quite frankly absurd speed improvements of VIM while also the great user-friendliness and ease of VScode

Re: Bill Joy's greatest gift to man – the vi editor (2003)

#109

Earlier quoted context omitted.

> I used vi and vim for about 25 years before switching to Emacs. Then maybe you can help:) I've tried, multiple times, to switch to emacs. And every time, I get stuck, because vim keybindings are so wired in to my muscle memory now, and even the broader interactions are hard to adopt (i.e., I expect to get a command prompt by escaping to command mode and then typing ":", and then all commands are available). Is ther…

I'd recommend using evil-mode. It'll give you the stock vim keystrokes and the command prompt (ie. what you get when you press the : key). I was tempted to say "just use evil-mode", but it's really not "just" a matter of using it. evil-mode doesn't get you everything, as many Emacs modes just don't have vim-like bindings, and you'll either need to rebind them all yourself to something that makes sense for you (which…

Yeah, IIRC I've tried Spacemacs and Doom... I think I managed to hit things that they didn't implement... oh, I know: I've gotten the (bad?) habit of going to normal mode by hitting ctrl-c rather than escape, and I think evil didn't handle that. (To be fair: It works in (neo)vim, but ctrl-c to get to normal mode doesn't work nicely in other vi versions either, which is why I suspect it's a bad habit and/or me abusing some misfeature that wasn't intended to be used that way.)

Perhaps I should take another swing at it and see if I can't deal with the quirks...

Re: Bill Joy's greatest gift to man – the vi editor (2003)

#110

Earlier quoted context omitted.

I used vi and vim for about 25 years before switching to Emacs. I did this because: 1 - I got deeply interested in Lisp and Scheme, and Emacs was reputed to have the best editing environment for these languages 2 - Almost all of Emacs itself and Emacs' entire package ecosystem is written in eLisp, which is a tremendous improvement over vimscript, in which almost all vim packages are written. I'd just rather read and…

>4) Emacs had packages that would emulate vim It's terribly inefficient for emacs vi emulation mode to actually quit emacs when you type ":q", because it takes much longer for emacs to start up than vi, and people use a long-running emacs a lot differently than they use disposable vi's. UniPress Emacs's vi emulation mode would actually flip you over to an emacs shell buffer when you typed :q, and the shell would reco…

"it takes much longer for emacs to start up than vi"

This is false on pretty much any modern system. They start up in about the same amount of time. Using lots of packages (in both vim and Emacs) will slow down startup speed, but there are tricks to speed that up too (like by defering actual loading of them until they're needed).

Also, most people who run Emacs just keep it running all the time, and almost never quit or restart it, so startup speed would not be an issue even if it was slow, which it isn't.

"people use a long-running emacs a lot differently than they use disposable vi's"

Emacs has an emacs-client binary which you can use exactly the way you use a disposable vi (or vim). It'll connect to the long-running Emacs process in the background, but that's an implementation detail that you as an Emacs user wouldn't have to worry about, apart from starting Emacs once when you boot your system.

Regarding your description of shell-flipping, Emacs does offer shell integration, where that sort of thing can be done, but I personally don't use it and run shells outside of Emacs (and run both my shells and Emacs itself under tmux), so my workflow with Emacs and the shell mirrors the traditional vi/vim workflow.

I didn't have to change my decades-old vim muscle memory or workflow when I made the switch to Emacs.

Post reply on HN