4 ms·

Enjoyable list but I’m not sure the AlphaGo documentary counts as pop culture :). It’s interesting how people talk about vi vs emacs, can’t remember ever meeti

by zingar 4mo ago

Enjoyable list but I’m not sure the AlphaGo documentary counts as pop culture :). It’s interesting how people talk about vi vs emacs, can’t remember ever meeting anyone who chose vi over vim, let alone enough people to make th at the debate.

jolmg 4mo ago
> can’t remember ever meeting anyone who chose vi over vim, let alone enough people to make th at the debate. Because vim generally offers everything vi has. vi does have one advantage though. It's a lot lighter. vim is like 5.4MiB in size with 82 shared library dependencies, while vi[1] is like 260KiB with 2 library dependencies (libc and ncurses). [1] https://ex-vi.sourceforge.net/ https://ex-vi.sourceforge.net/
- floxy 4mo ago
  For resource constrained systems, don't overlook busybox vi. https://k.japko.eu/busybox-vi-tutorial.html https://k.japko.eu/busybox-vi-tutorial.html
  - rmunn 4mo ago
    Right. Sometimes all you need is to edit a couple lines in a config file and get out, in which case hjkl, i/a, and Esc (and then :wq) are all the editor really has to implement. (And a few more movement tools like w/b and so on). Plugins? Colorschemes? You don't need 'em to edit a couple lines in a config file. (I'll grant that syntax highlighting that makes the comments a different color from the actual lines can be helpful, but if it comes at the cost of a much larger binary it's not always worth the cost on those resource-constrained systems).
bch 4mo ago
> can’t remember ever meeting anyone who chose vi over vim Pleased to meet you. Most of my console dev time is spent in *BSD, where nvi is where I land. I find the the default creature-features of vim annoying, so I end up having to configure it to be a bit more quiet, and I don't know anything so compelling about it (a vi clone (to an extreme, acknowledged)) that nvi isn't a good enough place to be. I have vim installed, but it's not my go-to.
- jolmg 4mo ago
  > I don't know anything so compelling about it For me, it'd be primarily having more than one undo. Not being able to undo the second-to-last change is pretty bad. In fact, vim's undo being set up as a tree that can be walked with g- and g+ is excellent. It's impossible to lose a state of the buffer, even if you undo and make changes. It's a lot more practical to navigate than Emacs' undo, too. EDIT: I just realized that nvi can undo more than one change by having u toggle the direction and . continue in that direction. I don't think ex-vi could. busybox vi seems like it can undo multiple with u but it seems to have no redo.
  - bch 4mo ago
    > For me, it'd be primarily having more than one undo Do you mean infinite undo? nvi has that. I'm not sure what you mean "set up as a tree" wrt undo, but i'll look into it. I think of nvi's undo as linear - I can 'u' to "undo" and implicitly set my "undo direction" "backward in time" (as one would expect). If I want to "undo, even more", '.' (dot, period) to "do that last command again" is what I'll do. If I want to "undo an undo", 'u'. That has the effect of moving the "undo direction" back towards the state of the buffer we had at the beginning of our discussion here. ...and, now I see your edit ;) ^[u..........:wq
    - jolmg 4mo ago
      > I'm not sure what you mean "set up as a tree" wrt undo :h undo-branches There's also a plugin to show a visualization of the tree, but the tree is implemented within vim. https://github.com/mbbill/undotree https://github.com/mbbill/undotree
      - bch 4mo ago
        Nice. I like it. Advanced history mgmt in between commits is compelling.
  - emil-lp 4mo ago
    > It's a lot more practical to navigate than Emacs' undo, too. What the heck are you talking about? Emacs undo is simply the State monad over a zipper into a persistent tree of buffer states. I can't see how you could make it more practical?
throw0101c 4mo ago
> can’t remember ever meeting anyone who chose vi over vim As a sysadmin, I prefer a basic "vi" as in most cases I want quick open/edit/close and don't need fancy colours and such. (I.e., vim.tiny on Deb/Ub rather than vim.basic.)

by zingar 4mo ago

jolmg 4mo ago

> can’t remember ever meeting anyone who chose vi over vim, let alone enough people to make th at the debate. Because vim generally offers everything vi has. vi does have one advantage though. It's a lot lighter. vim is like 5.4MiB in size with 82 shared library dependencies, while vi[1] is like 260KiB with 2 library dependencies (libc and ncurses). [1] https://ex-vi.sourceforge.net/ https://ex-vi.sourceforge.net/

floxy 4mo ago
For resource constrained systems, don't overlook busybox vi. https://k.japko.eu/busybox-vi-tutorial.html https://k.japko.eu/busybox-vi-tutorial.html
- rmunn 4mo ago
  Right. Sometimes all you need is to edit a couple lines in a config file and get out, in which case hjkl, i/a, and Esc (and then :wq) are all the editor really has to implement. (And a few more movement tools like w/b and so on). Plugins? Colorschemes? You don't need 'em to edit a couple lines in a config file. (I'll grant that syntax highlighting that makes the comments a different color from the actual lines can be helpful, but if it comes at the cost of a much larger binary it's not always worth the cost on those resource-constrained systems).

bch 4mo ago

> can’t remember ever meeting anyone who chose vi over vim Pleased to meet you. Most of my console dev time is spent in *BSD, where nvi is where I land. I find the the default creature-features of vim annoying, so I end up having to configure it to be a bit more quiet, and I don't know anything so compelling about it (a vi clone (to an extreme, acknowledged)) that nvi isn't a good enough place to be. I have vim installed, but it's not my go-to.

jolmg 4mo ago
> I don't know anything so compelling about it For me, it'd be primarily having more than one undo. Not being able to undo the second-to-last change is pretty bad. In fact, vim's undo being set up as a tree that can be walked with g- and g+ is excellent. It's impossible to lose a state of the buffer, even if you undo and make changes. It's a lot more practical to navigate than Emacs' undo, too. EDIT: I just realized that nvi can undo more than one change by having u toggle the direction and . continue in that direction. I don't think ex-vi could. busybox vi seems like it can undo multiple with u but it seems to have no redo.
- bch 4mo ago
  > For me, it'd be primarily having more than one undo Do you mean infinite undo? nvi has that. I'm not sure what you mean "set up as a tree" wrt undo, but i'll look into it. I think of nvi's undo as linear - I can 'u' to "undo" and implicitly set my "undo direction" "backward in time" (as one would expect). If I want to "undo, even more", '.' (dot, period) to "do that last command again" is what I'll do. If I want to "undo an undo", 'u'. That has the effect of moving the "undo direction" back towards the state of the buffer we had at the beginning of our discussion here. ...and, now I see your edit ;) ^[u..........:wq
  - jolmg 4mo ago
    > I'm not sure what you mean "set up as a tree" wrt undo :h undo-branches There's also a plugin to show a visualization of the tree, but the tree is implemented within vim. https://github.com/mbbill/undotree https://github.com/mbbill/undotree
    - bch 4mo ago
      Nice. I like it. Advanced history mgmt in between commits is compelling.
- emil-lp 4mo ago
  > It's a lot more practical to navigate than Emacs' undo, too. What the heck are you talking about? Emacs undo is simply the State monad over a zipper into a persistent tree of buffer states. I can't see how you could make it more practical?

throw0101c 4mo ago

> can’t remember ever meeting anyone who chose vi over vim As a sysadmin, I prefer a basic "vi" as in most cases I want quick open/edit/close and don't need fancy colours and such. (I.e., vim.tiny on Deb/Ub rather than vim.basic.)