[HN Gopher] The Evolution of Vi and Vim
       ___________________________________________________________________
        
       The Evolution of Vi and Vim
        
       Author : ibobev
       Score  : 107 points
       Date   : 2023-09-15 13:34 UTC (9 hours ago)
        
 (HTM) web link (pikuma.com)
 (TXT) w3m dump (pikuma.com)
        
       | otterpro wrote:
       | Good historical overview of vim and its origin. I remember using
       | vi for the first time at my university because emacs would slow
       | down to a crawl on our unix clone system especially just before
       | our computer science homework was due, and I was forced to switch
       | from Emacs to vi. During that time, Amiga was my home computer,
       | but I don't remember seeing it on Amiga. Most of my time was
       | spent at school on a Wyse VT-220 clone terminal. Since then, I've
       | tried Elvis, nvi, and few other clones until settling with vim
       | much later in life when Ruby on Rails came onto scene.
        
       | otherflavors wrote:
       | Probably worth noting is that elvis is the origin of nvi (New vi)
       | which is the default on the BSDs
        
       | dig1 wrote:
       | > most users found frustrating having to work with ed.
       | 
       | True, until you need it. And you'll usually pull out ed when any
       | other editor fails :D One example is an extremely slow ssh
       | connection. For those who can recall, when SourceForge allowed
       | ssh access, running vi/vim was a PITA if you wanted to edit
       | something. But not with ed.
       | 
       | The second example of where ed is unmatched is scripting - it has
       | the same "interface" for interactive editing and scripting (it
       | uses the same commands and command sequence). Someone also
       | mentioned (can't find source of the quote) that the same trick is
       | helpful when you write a book because you can easily print ed
       | command sequence readers can repeat and follow your examples,
       | which isn't the case with any other visual editor. You can write
       | unit tests to validate those things in case you want to ensure
       | your book examples actually work.
        
       | jurassicfoxy wrote:
       | Great article, thanks for sharing.
       | 
       | I love Vim, and although my usage is totally vanilla these days,
       | I use Vim plugin for VSCode which is awesome (lack of :norm is
       | the only downside I've found).
       | 
       | Vimium for Firefox is also a must-have
       | https://addons.mozilla.org/en-CA/firefox/addon/vimium-ff/
        
       | hrokr wrote:
       | It's interesting that the increase in Vim commits is concurrent
       | with the fist release of NeoVim. They've certainly both been good
       | for each other and I'm hoping this won't change with Bram's
       | passing.
        
         | The_Colonel wrote:
         | Vim was mostly a one man show. I doubt it will be meaningully
         | developed apart from bugfixes and such.
        
           | arp242 wrote:
           | > Vim was mostly a one man show.
           | 
           | No, it wasn't, and hasn't been since the 90s (most of the
           | gvim code was written by others back in the day, to give an
           | example of a large body of code not written by Bram). There
           | have been many people contributing, and some of them for
           | years.
           | 
           | Yes, Bram was the BFDL and the only one committing patches,
           | but don't confuse that with "one man show".
        
             | The_Colonel wrote:
             | There were of courses patches by other people, but most big
             | features were driven by him. Do you have some example of a
             | big feature more recent than 20 years old gvim?
        
               | [deleted]
        
               | arp242 wrote:
               | Most of the multibyte from the last few years for
               | example.
               | 
               | Bram didn't really record these things very well until
               | quite recently (and even then, rather inconsistently) by
               | just listing the author in the commit message rather than
               | the git author field, so there's no easy way to check.
        
         | turndown wrote:
         | Forking is usually good for the community around a piece of
         | software but I struggle to find who made this argument
         | originally
        
       | BoppreH wrote:
       | I've been using Vim for years, but if there was one thing I could
       | change, it would be the verb-noun order. The Kakoune[1] editor
       | behaves mostly like Vim, but where Vim has `dw` as "delete word",
       | Kakoune has it backwards: `wd`.
       | 
       | It might sound minor, but by placing the range first, Kakoune can
       | give a preview of what will be changed. The longer or more
       | complicated the command, the more this feature shines.
       | 
       | Strictly better as far as I know. A shame my muscle memory, and
       | all default installations, are still stuck with Vim.
       | 
       | [1] https://kakoune.org/
        
         | eminence32 wrote:
         | I've been test driving the Helix editor (mostly because of its
         | out-of-the-box support for a wide range of LSP servers), and it
         | adopts the kakoune style of keybindings. Like you, my muscle
         | memory is very strongly in the Vim camp, and is hard to change
         | :)
         | 
         | https://github.com/helix-editor/helix
        
         | smegsicle wrote:
         | prospective vim-learners should note that kakoune style is a
         | dead end
         | 
         | as noted nearby, vim's visual mode provides a similar interface
         | as standard
        
         | lawn wrote:
         | One major drawback of that model is that it makes textobjects
         | harder to use and are often relegated to more obscure commands.
        
         | wryanzimmerman wrote:
         | The vim equivalent of that is visual mode, eg `vwd` which is
         | exactly the same structure as you're saying you want from
         | kakoune.
         | 
         | So vim is verb-noun for simple things, but if you want, you can
         | use visual mode if you're doing something more complex or just
         | want visual confirmation first.
        
           | schnubbidubb wrote:
           | That's exactly what I do, because I need the visual
           | confirmation and can't really wrap my head around it
           | otherwise.
           | 
           | Sometimes when I don't realize I'm in insert mode, I jump
           | around the document and don't know what just happened. Visual
           | cues in-between would have been nice, so I don't always feel
           | as surprised as I do, lol.
           | 
           | Although I don't know if in that particular fiddly case it
           | would have any benefit.
        
             | lawn wrote:
             | Not noticing that I'm in insert mode isn't something I can
             | remember struggling with.
             | 
             | There are different solutions for it:
             | 
             | - Obsessively press escape so you're always in normal mode
             | 
             | - Style the statusline so it's very colorful when you're
             | not in normal mode
             | 
             | - Have the cursor be "fat" when in normal mode and "thin"
             | when in insert mode (isn't this the default?)
             | 
             | Even though I've been using Vim for 15 years or so I also
             | enter visual mode for some commands. It's quite useful, but
             | not necessary all the time (like di" for instance).
        
               | chaxor wrote:
               | Mapping escape key to another key is always useful
        
             | davisoneee wrote:
             | If you have a reasonably long `updatetime`, you could try
             | something like `autocommand CursorHoldI * stopinsert`.
             | 
             | On both vim and nvim, updatetime is 4 seconds, so if you
             | have 4 seconds of inactivity that autocommand will
             | automatically put you back into normal mode.
        
         | sph wrote:
         | Here's a rebuttal, why kakoune's model might not be better than
         | vim:
         | https://github.com/noctuid/dotfiles/blob/master/emacs/editin...
        
         | hiAndrewQuinn wrote:
         | If someone wrote a way to transplant strict Kakoune keybindings
         | into Neovim, I'd change in a heartbeat. Unfortunately I'm too
         | immersed in the plugin system as it is.
        
         | andrewla wrote:
         | My muscle memory can adapt. In terms of day-to-day use, I found
         | it nearly impossible to deal with the behavior of the key
         | combination "xd". "x" is "select-line" and "d" is "delete". So
         | this should delete the current line.
         | 
         | But if you're on a blank line, it will delete the next line,
         | not the current line.
         | 
         | If you can figure out why this is, then you are close to
         | understanding how kakoune manages the concept of "line" and
         | "cursor" and "selection", but for me this is an abstraction gap
         | too far. I can't make the conceptual leap. And once you
         | understand the line/cursor/selection model, you see that this
         | is unfixable.
         | 
         | Oh well, maybe Helix is the way.
        
         | jodrellblank wrote:
         | I've Vim for years been using, but if one thing I could change
         | there was, it the verb-noun order would be. The Kakoune[1]
         | editor mostly like Vim behaves, but where Vim `dw` as "word
         | delete" has, Kakoune it backwards has: `wd`. It might Germanic
         | sound, but by first the range placing, Kakoune can a preview of
         | what changed will be give. The more the command longer is, the
         | more the command complicated is, the more this feature shines.
         | It strictly better as far as I know is. A shame my muscle
         | memory, and all default installations, are still with Vim
         | stuck.
         | 
         | English swaps it around as convenient, so do common computer
         | systems - you can verb(data) or data.verb() in the more popular
         | languages and I think it's no coincidence that the popular
         | languages have both or the languages which have both became
         | more popular. If a choice is a toggle, one size nobody very
         | well it fits.
        
       | kaycebasques wrote:
       | The naming tradition interests me. Some of the name changes are
       | incremental: ed, then em, then en, then ex. Others seem like a
       | dramatic break: e* to vi. I'm getting the sense that it was a
       | more common tradition than I realized. Of course the classic
       | example is C to C++, which is just so dang satisfying. Are there
       | other interesting examples of incremental name changes and more
       | fundamental shifts (e* to vi)?
        
         | pluijzer wrote:
         | Not my favorite language but I like how C# is C++++ (even
         | though in musical terms C# would be inbetween C and C++).
        
           | layer8 wrote:
           | Arguably you only need two pluses to form a hash symbol.
        
         | cbm-vic-20 wrote:
         | :vi is the ex command to switch to visual mode.
        
         | tokyolights2 wrote:
         | In unix the names of things are just based on what stuck and
         | what was used. My favorite example of name evolution is the
         | jump from `more` to `less` (because less is more...)
        
       | [deleted]
        
       | Scubabear68 wrote:
       | As a footnote to history, Manx Aztec C shipped with a complete
       | set of Unix-like tools for non-Unix systems. This included a
       | partial VI clone of their own. So users of Aztec C for MS-DOS,
       | Mac, Amiga, Atari-ST etc all got VI clones as part of the deal.
       | 
       | I have been a VI user my whole life as a result (I worked for
       | Manx in the late 80's, and their flavor of VI was my first real
       | taste of text editing).
        
       | atan2 wrote:
       | What a great article!
        
       | BaculumMeumEst wrote:
       | Although it will never be as popular as Vim, I will always see
       | Kakoune as the evolution of Vim. It improves on so much and adds
       | very well thought out functionality. Object-verb works very well
       | when you adjust, and structural regular expressions make a lot of
       | operations much less painful.
       | 
       | Built-in multi cursors and autocomplete without fiddling with
       | plugins is wonderful, and the in-editor discoverability and
       | documentation is great.
       | 
       | It retains Vim's spirit of minimalism but cuts out a ton of cruft
       | without constraining itself to any kind of backwards
       | compatibility.
       | 
       | I use Kakoune as my $EDITOR and VS Code with Dance for software
       | development. I think Dance does a great job of leveraging Kakoune
       | and VS Code's strengths. I wish there was an equivalent for
       | Intellij as well.
       | 
       | https://marketplace.visualstudio.com/items?itemName=gregoire...
        
       | hiyer wrote:
       | I'm privileged enough to have worked with one of the people
       | mentioned in the article - Tim Thompson, the author of Stevie.
        
         | fritzo wrote:
         | More recently Tim Thompson has been creating interactive art
         | installations. I got to work with him at some installation
         | shows in the bay area https://timthompson.com
        
       | [deleted]
        
       | baudaux wrote:
       | For people who do not have vim installed, you can try it in
       | https://www.exaequOS.com, an OS running in a web browser (that I
       | am creating)
        
         | baudaux wrote:
         | There is ed as well
        
       | gustavopezzi wrote:
       | Author here. Thanks for sharing!
        
       ___________________________________________________________________
       (page generated 2023-09-15 23:02 UTC)