Vim's 25th anniversary and the release of Vim 8
lwn.netFun fact about vim:
When vi was originally designed the most popular keyboard was ADM-3A and later IBM XT https://en.wikipedia.org/wiki/IBM_PC_keyboard#/media/File:IB... The layout of this keyboard has Control on the place where modern keyboards have a CapsLock key. Naturally that's why vi and vim was meant to use CTRL-[ to exit to the normal mode.
25 years later Apple introduced ToughBar and made ESC key virtual. As result remapped CapsLock-[ make sense again ;)
edit: Add ADM-3A keyboard
> when vi was originally produced most popular keyboard was IBM XT.
Probably not, since the IBM XT was five years in the future.
The canonical vi keyboard is the ADM-3A. http://terminals-wiki.org/wiki/index.php/File:Lear_Siegler_A... Escape is almost as accessible as Control.
The ADM-3A also explains why shells use ‘~’ to represent the home directory.
I was curious about some keys I hadn't seen before, so for anyone curious, here's the purpose of the "rub" and "here is" keys (from the ADM-3A operators manual[0] page 3-7 and 3-8):
RUB. When the RUB (rubout) key is typed while holding down the SHIFT key, a non-displayable rubout code (ASCII DEL) is transmitted to the computer. The cursor is not advanced and the character code stored in display memory is not overwritten. RUB is normally used to tell the computer that a previous character should be deleted.
HERE IS. If the Answer Back option is installed, typing this key transmits an identification message (stored in a special ADM-3A memory) that identifies the terminal and alerts the host computer that a message is to follow. If no Answer Back option is installed, the key has no function.
For the reason DEL is shifted ‘_’, see your friendly neighbourhood ASCII table, and/or one of the recent HN threads¹. The ADM-3A² is a good example of a bit-paired keyboard³.
¹ https://news.ycombinator.com/item?id=13539552
You're right, thanks for your correction. My main point was a location of the Control key. I guess with IBM XT keyboard CTRL-[ become a most reasonable option https://en.wikipedia.org/wiki/IBM_PC_keyboard#/media/File:IB...
Also notice the arrows on H J K L.
Promoting bad habits. Don't use the left-right arrow keys to move around!
The left - right with the H J K L keys? Or the normal Keys ? And why is this a bad habit?
Moving around with hjkl is a bad habit to be discouraged. It's not the vi way.
Well, j and k are fine if you're not moving far. A lot of slow scrolling up and down should be { and } or C-d and C-u or <count>[jk]. Even better: Use / and ?. It's bad to be repeatedly tapping j and k or waiting for the keys to repeat.
But h and l are the EMACS approach. You should be moving in a line with w, e, b, f, F, t, T, ^, $, I, A, 0, and the like. Vi provides lots of tools for efficient line editing and h and l are not good.
Beginners should try
to keep them from the temptation of the nefarious h and l keys.:noremap h <nop> :noremap l <nop>Lately I use
which is even better because ^ and $ require moving your hands off the home row even though they're much better than h and l for you.:no h ^ :no l $Huh. The "vim way" goal posts have moved even further. Used to be "no-op your arrow keys and use hjkl", now it's "noop your hjkl keys".
Something I, as a dedicated VIM user, will never do. 'hjkl' work fine, and are a good addition to 'we{}$0' and so forth. I can't personally find the value of hobbling myself for the sake of meeting someone else's definition of the ideal user.
I even occasionally use the arrow keys. Heresy, I know.
> The ADM-3A also explains why shells use ‘~’ to represent the home directory.
Is that also the origin of '^' being start of line in a regex?
Good guess, but no. The ADM-3A dates to 1976, but the regular expression syntax is definitely earlier: https://www.bell-labs.com/usr/dmr/www/qedman.html
Wow this is a better and cleaner/streamlined keyboard layout than I have on my 2015 MacBook Pro :(
Actually I have remapped Caps-Lock to ESC and when pressed longer than a few ms to Ctrl system wide for years, with the Karabiner app.
I read about that neat productivity boost that also reduces the strain on your left hand a lot in a blogpost which "sold" this idea as "this is how VIM was intended to work" and I really love it. Useful even for normal terminal combos like Ctrl+C.
Only downside is, once you get used to it, you just can't go back ;-)
Sadly on macOS Sierra, you have to use Karabiner-Elements, which doesn't (yet, I hope) include support for long-press=ctrl.
If you're fine giving up caps lock, Sierra makes it easy to remap caps lock to esc in Systems Preferences (it even disables the little green light on the key)
Sadly, that isn't as powerful as what our comment-ancestors do with Karabiner. Such an accessible and prominent key as Caps Lock is, IMHO, wasted if only used for ESC; using it both for Control when in combinations and ESC when alone makes the most sense.
I use Caps Lock for Cmd or Ctrl, depending on which keyboard I'm using, and <Leader><Leader> for Escape on Vim.
I don't know where I got this idea from, but I also use <Leader>w to exit to normal mode and save. It's so ingrained in me, that when I use other editors very often I have "Unexpected token" errors because of a ",w" in the middle of the code.
Wow, that's news to me! How I've waited for Apple to do this. Karabiner-Elements does some shady stuff with the kernel and in my experience makes the machine a lot less reliable.
There is a pull request to implement this feature: https://github.com/tekezo/Karabiner-Elements/pull/247
I haven't tried it myself. Honestly it's one of the things keeping me from upgrading to Sierra. Need to test it out first.
I am surprised to learn that the set of people who use vim and the set of people who have patience to "long-press" intersects!
FWIW you can also use Keyboard Maestro to solve this problem.
I use Keyboard Maestro for exactly this purpose. For the most part, it is great. However, it does just stop working every now and then, at least for me, which is mildly irritating.
> once you get used to it, you just can't go back
So true. So many capital letters typed and deleted.
Any way to do the remap with Gnome on Linux?
gnome-tweak-tool --> Typing --> Caps lock key behavior --> (near the bottom) select the swap option
Also worth noting: Ctrl+[ = ESC in ASCII, which is where the keyboard shortcut comes from.
And it is processed not by Vim itself, but by the terminal emulator that sends Esc character to Vim. So the shortcut Ctrl+[ was not invented by vi author, but is a consequence of using Esc to exit from the edit mode.
That's fun but not a 'fact'. The ADM-3A keyboard had an 'ESC' key and it was positioned right where the tab key is typically today. Very easy to hit.
Here's a write up with nice pictures.
http://www.catonmat.net/blog/why-vim-uses-hjkl-as-arrow-keys...
Why does a combo with two keys on opposite sides of the keyboard make sense? Surely something that can be hit with one hand is easier?
I'll have to try this for a week.
I personally find using two hands for pressing key combinations more comfortable than holding a modifier key with a pinky and reaching for the other key.
Right, but wouldn't you prefer using one key?
Because Ctrl+[ = ESC in ascii
Back then there was no mouse so both of your hands were on the keyboard full time. If you have two hands, it's a shame not to use them both.
Why not use "jk" or "jj"?
These can be convenient if you are only entering text manually. But remapping regular -- albeit rare -- text sequences can have unexpected results when pasting copied content into insert mode in a terminal window. I've been bitten by this a couple times when pasting base64-encoded data.
This has caught me as well, but it can be avoided by using `:set paste!` to toggle paste mode before pasting. This isn't something I need to worry about often enough but you can map that command if pasting external content is something you do often.
Most terminals support bracketed paste, and vim can automatically toggle pastemode based on the special sequences.
Discovering this really changed Vim for me. That and remapping j and k to move over visual lines instead of logical lines.
What if you want to write "Dijkstra"?
That's why i use kj.
(Also: quaternions)
Then you wait one second after pressing j (until the timeout is over) and press k.
To be quite honest, that sounds terrible.
I don't think it's bad at all. I very rarely have to write 'jk', and using that combination saves me from having to either reach the escape key or having to use c-[. If the price I have to pay is waiting 0.5s (which is what I have the timeout configured to) once in a while, then I consider this a great tradeoff.
Caps Lock is one key, easier to type, and even more rarely used, though. I highly recommend it. =)
That's what I use too :). I also highly recommend it. I would strongly recommend binding either escape or ctrl to caps lock on every keyboard.
Or you press `<C-v>` before the `j`.
Then you need to switch to Dutch mode...
Personally that slows down normal usage of j too much for me.
It doesn't have an effect if you type a single `j`.
I've been using <leader><space> lately, with space as the leader key so just <space><space> really, it's worked well so far.
Try it for a week; you'll love it.:ino kj <Esc> :ino <Esc> <Nop>
My employer bought me a macbook with the touchbar and I've had to retrain my muscle memory to use C-[. It took a couple of weeks for it to feel natural but it wasn't nearly as bad as I expected it to be. I still haven't found a killer app for the touchbar, though.
Me neither, but the TouchID is terrific.
For me the best way to have an accessible ESC key is just to use Alt-h, Alt-j, or just pressing Alt with any normal mode key. It will work on any vim installation out of the box, it is easily accessible and doesn't require remapping.
As long as your terminal is configured to send the Meta modifier as an ESC prefix rather than a shift bit, and as long as your Alt key serves as Meta.
I've set my capslock to be escape and my alt to be control. I don't know where my alt is, but I've never really used it. (I think the only usecase for alt is Alt-Tab to switch windows, but that always feels epically unpredictable to me. What's going to happen? ... I prefer just clicking on the window I want).
An aside, PC XT keyboards can still be found on ebay for ~$40 and are great to use after being adapted and remapped with a microcontroller.
In the early 2000s, I was at a friend's place with John "maddog" Hall, who was talking to a group of us about the future of software and the promises of quantum computing.
He said something that I always found interesting. He was talking about how in a decade or so we would probably be using software and tools that would be unrecognizable to us at that moment, but after a pause he added: "but we'll still be writing code with vi." :)
Having used Windows, Linux, Visual Studio, Eclipse, and Perforce in both the early 2000s, and today, I'd daresay that they are quite recognizable. Much more usable (Except for Eclipse), but still quite recognizable.
I'd agree with that.
I actually can't think of a tool I use day to day that I wouldn't recognise from 20 years ago even the really good stuff would be obvious in it's intent (intellij etc).
I'm not really sure where I'd be able to improve significantly on day to day tool usage, maybe a shell that doesn't use bash as the language would be nice (I know there are other shells but bash/dash are the defaults on pretty much everything I touch I can get to a command line on).
Slack app on your smartphone?
That's just IRC on a small computer though.
Sometimes the 'just' is where the magic is, we all know that slack is just a pretty irc that end users can grok.
That 'just' is worth a fee billion dollars though.
Makes you wonder if there are other tools in our world that could be a 'just' away from a billion dollars.
Sure but I think that it is still recognisable, which was the question.
25 year ago isn't //that// long ago? People using IRC at that point (I guess techies) surely would recognise it fairly easy.
Similarly you could look at a brand new Tesla and recognise it from a 1st car model or even a wagon.
People using IRC at that point (I guess techies)
College students, mostly.
I think I first used it ~1995 so that would be 22 years.
Hung around for about 5-6 years and it's been around in the background ever since, just got back into using it recently as one of the frameworks I use has a decent IRC channel and an even more decent offtopic, nice bunch of folks and with the ability to throw it in the background it gives a water cooler feeling when I'm working on my own and need to bounce an idea of people.
So, he was right about at least one thing then. :)
Not sure why you're getting down-voted. Development tools look pretty much the same as they did in 2000, languages all feel quite similar, and quantum computing still isn't ubiquitous. We are, indeed, still using Vim though, and quite happily, I might add.
CI and deployment tools have matured a lot. I'd call them development tools.
Vim is great, but hard out of box. That's why I'd like to mention couple community distributions to make it even better:
• http://vim.spf13.com this distribution is remarkable! Extremely well documented vimrc file is a great source of knowlege by itself https://github.com/spf13/spf13-vim/blob/3.0/.vimrc
• https://github.com/carlhuda/janus
Also, it worth to mention
and
I would recommend against starting with someone else's pimped out configs and go with something more conservative. Tim Pope's sensible.vim is a good starting point. It has "sensible defaults" but no opinionated keyboard configs, extra plugins or so.
https://github.com/tpope/vim-sensible
That's pretty much all I have, plus a few personal shortcut keys and some syntax highlights that aren't included in vanilla vim.
It's pretty short, I recommend copying it to your .vimrc, understanding every line (:help) and modifying to taste.
Vim-sensible is the first, and sometimes only, vim plugin I use. It is small, takes care of most of the stuff I had in my personal .vimrc file and works across all of the systems I am on. I used to just load up vim with tons of plugins until I realized I used about 5% total of everything I was loading in.
These days it's vim-sensible,vim-go, syntastic and the base16 themes.
For me it's a matter of mental overhead. When I used to tweak every little setting and install a plugin for everything, it was so much work, for, and let us be realistic, very little gain in the long run. Now I usually run defaults with some bare essential tweaks that is obvious improvement on my "quality of life" - and if I cannot automate the setup it needs to be required or I'm not doing it - that is it.
I understand why someone would want to start with a prefilled vimrc, but I really can't stress enough how useful writing your own vimrc is. I started with bits and pieces from everywhere on the internet, but one day, I sat down and wrote my own vimrc. I realized I didn't even know 1/2^32th of the things that were possible with vim!
I used to customize vim quite a bit, but I got tired of trying to sync my config across multiple systems, some behind corporate firewalls.
I run into this with TMUX too. It's a pain when you are used to your specific config to the point that it's hard to use the default config.
I got into emacs when I started lisping, but vastly prefer vim's keyboarding and macros. So when spacemacs came about, I jumped on board and love it. The power of emacs and the sense of vim.
Plus, I don't have to customize spacemacs aside from enabling modules I want... very easy to do. Very easy to keep in sync across multiple machines.
If `git pull` works, I recommend just putting all your dotfiles in a git repository. If `git pull` doesn't work, then you've got Problems.
Or you know, you're ssh'd into a machine, that other developers use, too; has specific networking requirements, etc..
For shared accounts, it's really annoying if others mess with settings. For that reason, I use the following piece of shell code that I put in .bashrc. Explanation: you configure the MYMACHINE variable as the IP address you usually come from.
# If we're logging in through SSH, write this down if [ -n "$SSH_CLIENT" ]; then # Alternative settings MYMACHINE="172.16.140.14" FROM=`echo $SSH_CLIENT | cut -f1 -d" "` case $FROM in *$MYMACHINE) export TMOUT=180 #Logout after 3 minutes set -o vi # all sorts of other settings ;; esac fiYep. I spend all day connected to machines that I have to access through a jump server because they have no direct internet access in or out themselves. No way is it worth it for me to customize anything there.
I realize that this is a pretty rare situation though.
I find TRAMP (https://www.emacswiki.org/emacs/TrampMode) invaluable in these situations. It lets you run shells/edit files on remote machines from within your local Emacs. There are a few quirks that you need to get used to, but it makes Emacs + a bunch of regular Linux boxes into something that feels very Plan-9-y.
In your case, you would want to look into the multihop settings that will let you open files and eshells on remote machines, but use an intermediate machine (your jump boxes) to get there.
>I used to customize vim quite a bit, but I got tired of trying to sync my config across multiple systems, some behind corporate firewalls.
Mine is on github. https://github.com/milesrout/.vim
I can operate without it, though. The only thing is that I always have swap : and ;.
That's very true. On other hand based on my experience from San Francisco Vim meetup many beginners give up because of a steep vim learning curve at the beginning.
It's better to start from something that already solves code editing problems and then customize it or even rewrite rc from scratch.
I highly, highly recommend people write their own vimrc from the ground up and add plugins as necessary.
That option doesn't make a lot of sense when it's as difficult as it is to know what options can be cusatomized, and in what ways.
I agree that things should be gradual, but having a commented config that people can reference and say "Oh, that sounds super useful actually" seems like a good thing to me.
I switched to NeoVim last year and couldn't be happier. It's stable, everything works, it has nice defaults and it gets updated all the time.
I switched because there were several bugs in Vim that drove me nuts and they weren't being fixed by the Vim team. One person suggested NeoVim and to my delight, these bugs were not present in NeoVim. I immediately donated $20 to the NeoVim team because I was so happy.
What are the bugs?
After using vim for many years with a basic .vimrc, I pulled in spf13, and wow, how little I knew!
I know many suggest learning vim from the ground up, but I'd say there's benefit to learning from the top down as well. Stripping spf13 down to the bits I'm interested in was an incredible learning experience.
For servers I still roll with pretty minimal configurations, but for local dev quite happy with an spf13 based .vimrc
No, Vim is not "hard" at all.
Vim is "complex", though, and it requires investment, just like any professional tool. One would be a moron to think he can master Photoshop, Fontlab, or Pro Tools in a week and one would be a moron to think one of those crappy distributions will make him master Vim in a week.
If you don't want to invest in Vim just use something else.
Yeah. I'm always baffled by these programmers complaining about the learning curve of vim or Git. Guess what, good tools are complex and you'll have to learn to use them and practice using them in any profession.
I wrote a minimalist vim config with install scripts based on spf13. I wrote it for myself, so I just took out a lot of unneeded options and tried to keep the scripts lean. I encourage people to check it out, clone it, make it their own.
I really prefer the VSCode approach here of editing the config file in a split window with one pane of all options with their default settings and a description of what they do, and a config file which can override those defaults.
neovim also has interesting discussion on default settings
It's not 'hard'. It's 'sparse'.
There is a learning curve with any tool.
I don't see why he felt the need to halfway add in package management, but not go all the way. You still have to download the package and update it manually from what i can tell... where the others you simply add a github path (or other repository path) and updates come eaily, install comes easily.
Consider the case of people like me who work on remote servers, who spin up new vagrant boxes and work on them remote... with the package manager as he described it, i'd have to download all the plugins and manually place them, etc... as i currently stand, i install vundle really quickly , then it just reads my .vundlerc.bundles and installs all the plugins i want, presto. Half solutions are worse than no solutions... because now people will compare the two, and default (likely) to the default solution and make package management harder on themselves than it needs to be...
I don't know you, but personally for something as sensitive as an editor that I use to work on code, I do NOT want automatic updates or the editor to connect to random websites to pull code I have not inspected.
I would rather have a directory with a few plugins I vet, and scp that around the place if needed. I am actually getting a bit get-off-my-lawn with some extensions in emacs that are all "manual installing is not recommended just use melpa"
Some do, some don't, but the person you're replying to only mentioned manually updating, which is how many (all?) Vim package managers with.
Then if you do want auto-updates you just call "PlugUpdate" in your .vimrc
The analogy I imagine is the node_modules folder--you build the minimal infrastructure to make a package manager possible, then let someone else come along and figure out the best way to actually make it (i.e. npm, but also ied and yarn).
I don't understand your concern. It seems to me to be roughly the same amount of work whether you A) install vundle and maintain a list of plugins for it to fetch or B) write a bash script that fetches each plugin. I actually prefer Vim 8's approach.
Because i can install vundle with a single line in my setup script (already have a "provisioning" kinda script for each time i fire off a machine).
I dont have to update that script for new plugins, its a single "Vundle user/repo" in the vundle.rc file. Vundle then installs it, and handles it.
Could it be scripted, sure... but its much more readable in the vundle form (or other managers for vim), and its also in a more logical place... and its portable, even to a windows machine... its kinda a separation of concerns kinda thing...
> I dont have to update that script for new plugins, its a single "Vundle user/repo" in the vundle.rc file.
You either add a single line to your vundle.rc file, or you add a single line to your bash script.
Still doesn't address separation of concerns... if you prefer a single monolithic script to do everything, thats cool, im not trying to change your mind, but for my tastes, i want my provisioning script to be as simple as possible, concerning only what it needs to, and let the apps configure themselves in a way that is obvious to anyone who uses my scripts (a few of my fellow devs use my stuff to bootstrap their setup)
Also, disabling plugins is much easier... just comment the line... instead of delete the folder. That way, if im working through an issue that a plugin is causing, i can easily just toggle the plugin. Vim just loads whatever is in the folders, so i'd have to delete the folder, then readd it when i want it back... its less of a use case, but since i write vim plugins from time to time, its nice to be able to easily turn on/off my own plugins that may have bugs in them when i need to actually work...
> User demand for a multi-threaded Vim (e.g. a patch for supporting multiple threads) and its rejection is what prompted the Neovim fork in January 2014. In his presentation, Moolenaar concedes that Neovim did create some pressure to add a way to handle asynchronous jobs.
I switched to neovim a while ago, because it supported 24-bit color themes in the terminal. Since then it seems even regular vim picked it up too. It's good to see that some pressure moved the project forward in different areas which were stuck forever before.
Though neovim already uses XDG base directory specification, but vim still doesn't.
> Though neovim already uses XDG base directory specification, but vim still doesn't
Aaaaand now I want to switch to neovim.
It's pretty effortless to switch. For me, I found: .vimrc was compatible (but lives in .config/nvim/init.vim). Plugins were compatible (in fact, YouCompleteMe worked better). There was a little bit of faff setting up symlinks. In case you use Arch, it offers a package neovim-symlinks that handles that for you.
Good to know, thanks.
Best place to start vim journey http://vimcasts.org/episodes/page/7/
CMU also has a pretty good guide/list here: https://www.cs.cmu.edu/~15131/f16/topics/vim/
Links this great stackexchange post 'Your problem with Vim is you don't grok vi' (Vim as a language) http://stackoverflow.com/questions/1218390/what-is-your-most...
I'm rather a fan of Vim Adventures. It's cool enough even my 8 yr old daughter wanted to learn Vim to play.
I love VIM... but I feel like VIM's life is coming to an end... as VIM. NeoVIM is just... better. The editor as it stands now is essentially the same, but an actual active development that isn's a single contributor is going to create a better project, and its going to respond to the community more and keep itself more up to date and performant.
I feel bad, in a way, because i have a strong loyalty to vim, but Bram's stubbornness at playing well with others is basically holding onto sand, and we know how that analogy goes...
"actual active development that isn's a single contributor is going to create a better project"
Depends on what your definition of "better" is. If you just want stable software that's bug free, multiple contributors might actually make the software worse. A lot of people use vim in a way such that Neovim will be no improvement.
Neovim could become like the next zsh. I use zsh every day and have for years. I think it's "better". But for most people bash is good enough so they use it. The things that are better in zsh are not things they care about, so they will not bother switching.
I'd be okay with that result (bash : zsh :: vim : neovim). Whatever the result I think vi(m) users are winning in the end. One side benefit of neovim existing is a push for vim to get similar feature and step up their development efforts. One difference I see with this comparison is neovim's goal: `feature-parity and backwards compatibility are high priorities`. If they succeed in this then there'd be little downside to switching.
Every mention of Vim turns into promotion of NeoVIM. Perhaps submit a story about NeoVIM if you want to talk about it. And what value do comments like this add? How am I better informed after reading it?
> NeoVIM is just... better
> an actual active development that isn's a single contributor is going to create a better project
Seriously? Since Vim was first released, probably there have been millions of software projects fitting the latter description that have not been nearly as successful as Vim. There are millions of them on Github right now. And don't forget the personal attack:
> Bram's stubbornness
If stubbornness produced Vim, we need a lot more stubbornness in software development.
>Every mention of Vim turns into promotion of NeoVIM.
I understand the frustration, but doesn't every Hacker News thread have a thread about alternatives (usually including some promotion)? I mean, every Vim thread includes a discussion of Emacs, too.
True, but as someone that visits places specifically for vim like (/r/vim) it get's particularly annoying. It's not that it's out of place here, is just a cumulative effect (for me personally anyway) from hearing about it where it doesn't belong.
I used vim for 20 years, up until about a month ago when I tried kakoune. It's got a new approach to modal editing that I really dig, which makes me realize the thing I loved about vim was that for a long time it was the best modal text editor around. I still think vim is a great project, but kakoune takes a refreshing approach that really clicked for me.
Don't hold back on us: What are the differences? The strengths and weaknesses?
Fair question!
Grammar: kakoune is heavily oriented towards selections. Things that happen in normal mode operate on the current selection. It's like using visual mode in Vim, except it's always on. It takes a little getting used to, since any cursor move changes the current selection. Part of its selection orientation is excellent support for multiple cursors.
Platforms: POSIX only. No support for odd platforms. If you want to use it on Windows, you have to use Cygwin.
Packaging: basically non-existant. You pull it from github and build it yourself.
Maturity: kakoune doesn't have version numbers as far as I can tell. I've had it crash on me, but it's rare.
Community: tiny but vibrant. There's #kakoune on freenode, which the core team seems to monitor pretty actively.
Syntax highlighting: yes, and it's more flexible than vim's. You can use it to roll your own colorcolumn, for instance.
Code folding and line wrap: these aren't there in kak, and I do miss them, but not enough to go back to vim
Tmux integration: awesome in kak, absent in vim. One of my new favorite things. In general, you can have multiple editors attached to the same session.
Automation / configuration: There's no such thing as kakscript, which I see as a plus. Nevertheless, you can do a lot of stuff here; I haven't scratched the surface, but there are lots of interesting example kakrc files out there.
Thanks for pointing out this project. It looks interesting.
Just to your point on packaging.. I googled and had it installed and running on Fedora in about 5 minutes after reading your post.
There are individual instructions and packages for many distributions listed here:
https://github.com/mawww/kakoune#2-getting-started
On Fedora it was literally 2 commands to install:
$ dnf copr enable jkonecny/kakoune ; dnf install kakoune
And then just "kak" to run it and play around a bit :-)
I suppose I must have seen those options and thought, "I might as well build it myself." I stand corrected!
Two main differences for who comes from vim in my opinion:
1) Editing model based on (multiple) selections. Instead of moving around and issuing verbs on objects, as in vim, you are always selecting something and the command (delete, change, yank and so on) comes afterwards.
It may not seem very different from vim, but the huge advantage is the feedback that you get from the editor.
2) Scripting kakoune is totally different from scripting vim and somewhat harder. If you need something in vim, you write your vim script and that's it. You can't do this in kakoune because the editor language is not a programming language, but only allows you to communicate with the system.
This is the reason why POSIX is a hard dependency, every script in kakoune usually relies on POSIX binutils to do things.
I've been learning to use UNIX more since I've started to use kakoune.
If your interested in text editors then it's worth watching some youtube videos on kakoune. There are some great ideas in there that even the old dogs could learn from. Actually, a lot of us could learn from it when it comes to things like feature discovery, it's a really good example of complex yet easy to use software.
The reason I haven't switched is because I prefer vims command->motion over kakounes motion-command, which doesn't quite sit well with me and because I don't like the scripting choices they made.
Can you point me towards some YouTube videos on kakoune? Literally cannot find one.
Sorry about that, I can't find any youtube videos either, I must be mis-remembering. I would recommend trying it out though, you don't have to spend long to see many of it's better features.
my take: the main strength and weakness is that kakoune is visual mode by default, so you see the effect of your text object commands without guessing (c3fx? c4fx?). having something always highlighted can be annoying.
Kakoune is neat, but the lack of a windows version makes it a non-starter for me (I need Windows, Linux, OSX to cover my use cases).
If running cygwin doesn't annoy the pants off of you, it works great in MinTTY/tmux.
If your running cygwin it's easy to build.
Thanks for the pointer. I am getting more and more frustrated with Vim (and neovim is not what I am looking for) and looking for alternatives.
I did try "vis" a while ago and it was alright but not quite there yet. And it was a bit too "sickness" for my taste, e.g. requires shell scripts for completion to ":open".
I do intend to try it again some time but I'll also give kakoune a go.
I haven't tried vis, although it too looks like a pretty solid project.
> I did try "vis" a while ago and it was alright but not quite there yet. And it was a bit too "sickness" for my taste, e.g. requires shell scripts for completion to ":open".
With regard to that particular issue, kak has a great fuzzy-finder.
edit: It also apparently integrates with ranger, although I haven't tried that.
It works very well but is still work in progress.
I appreciate that it's "just an editor" and not a half-assed IDE or an application framework. But I think they might have taken it a step too far.
I've been using `vis` for a while now, and I agree that it used to be overly minimal, but I've submitted enough issues that it now fits my workflow. Once you get past the friction of it not being vim, you can enjoy multiple cursors, a sane scripting language (Lua), sam's structural regex....
Yes, it's time to start thinking about the next twenty years.
Moving vim from a single threaded process to more of an asynchronous server framework is the right move. Emulating vim commands in other editors just doesn't work, we need to turn the edit and command modes into a service.
I also like the endorsement on lua. I'm eager to move my scripting away from vimscript.
A HUGE advantage for vim is that you can login to any server, new or legacy, and it will have vim. At least it will have vi.
Guess it would depend a lot on the dev, but it seems like NeoVim would make sense for one's personal computer, and then Vi/m whenever logged on to a remote server.
I'm a vim neophyte, but it's not like your .vimrc follows you along to those remote servers anyways so things would be different anyways working on a server?
> but it's not like your .vimrc follows you along to those remote servers
It could follow you. In the recent discussion of TMUX some people said that they have remote systems configured in such a way that the personal config files are automatically downloaded when they login as their dedicated user. All you need to do is to put your dotfiles put your dotfiles on S3 (IIRC), download happens on first login (again, IIRC).
In other words, "your config doesn't follow you" is more of a philosophical problem rather than a technical one. Personally, I think it's a bit silly.
I mean, you wouldn't normally think of running Nginx, Supervisord, Redis, Postgres, etc. without config files, so why do you (people who are against personal configs on servers) insist that we use Vim, Emacs, Git, Tmux, etc. without one? Using Vim (less so than Emacs, but still) without your .vimrc is like using Nginx with default nginx.conf. You can still serve static files if you can find your htdocs dir after all.
A sane global (system-wide) config for the tools would solve some issues, but that's a first step towards personal customization (which, as mentioned, is unacceptable for some people), so in practice we're mostly stuck with nearly unusable tools when we work on remote servers...
Ok, I feel a bit better now, sorry for ranting :)
> but it's not like your .vimrc follows you along to those remote servers anyways so things would be different anyways working on a server?
That's why I don't really customize vim at all, or make fancy macros, or any of that. I work on a half-dozen different machines and OSes every week, I can't be bothered to customize those environments just to lose them every time I re-format.
You could just make config downloads automatic on all your servers, see my comment below.
Doing this - not using customizations - means you're forfeiting 70%-90% of functionality and power of those tools. I don't think it's smart, but well, it is your choice.
Can you describe what you like to customize? I find I spend far more time thinking about code than writing code.
> Can you describe what you like to customize?
With pleasure, actually! Just today I thought about writing a blog post on this topic and seeing your request made me resolve to do it.
I'll post a comment here once I'm done, thanks for waiting ;-)
Sounds cool :)
You can have a simple fabric script to copy .vimrc (and .alias, .bash_profile, etc) copied to a new server. You don't need sudo for any of this.
Doesn't have to be fabric, just a shell script with scp. If you can ssh to a server you can copy dot-configs to your $home dir.
my vimrc (and all my dotfiles) are kept in my private github so, with a single git command, they travel right to me... :)
This is so nice and so much easier than it seems. And there's no need for a private repo; unless you're ashamed of your dotfiles, you could keep them in a public repo.
They are in a private-ish... its my company's internal... because i do share it with coworkers, but it does setup a lot of environment variables specific to our products, so its not fit for general public consumption :)
I will agree once neovim ships on the major platforms and has functions on par with vim. Their next milestone for Windows support has continued to slip. It's been at 75% complete for many months. Meanwhile, gVim is running great on numerous platforms.
It's not a knock against neovim, but I just hope they can keep things going.
Is it possible that Windows users are not as interested in vim as *NIX users for historical reasons, and therefore don't care as much about support?
Where it works, it's a drop-in replacement for VIM, notwithstanding differences in async implementations now.
It's certainly not a drop-in replacement for vim. It doesn't support many features released in vim 8.
Until vim 8, it was a drop-in replacement, retaining full compatibility with vimrc and all plugins. My switch was seamless, and that was a big goal of theirs. Vim 8 introduced features already found in neovim in an incompatible way, and now the real fork begins.
Well it isn't a drop-in replacement now. And it wasn't a drop-in replacement before either, on the platforms they needlessly removed compatibility with.
Vim introduced features that had been being worked on since before NeoVim, in a way that actually made sense in the context of Vim, and which fit into Vim nicely.
When trying NeoVIM I found it completely unusable because of a single bug: https://github.com/neovim/neovim/issues/2035
Hitting ^[ needs to be utterly responsive, but this causes that input to take up to seconds to be accepted. I've tried the suggested workarounds in tmux, etc. but the problem stubbornly persisted so I gave up. Will have to check back once that is fixed.
This brings me to a larger point - with Vim I can throw just about any environment/file type/file size at it and expect it to work. NeoVIM is not there yet so it's going to stay on the "try again in the future" list.
I had the same problem in terminal Vim.
This fixed it:
" leave insert mode quickly if ! has('gui_running') set ttimeoutlen=10 augroup FastEscape autocmd! au InsertEnter * set timeoutlen=0 au InsertLeave * set timeoutlen=1000 augroup END endif
How is NeoVIM better than vim?
Never tried NeoVIM; VIM is very customizable, so for me its ok as long as I can customize it.
The most confusing vim thing for me was to learn vimscript (when doing plugins), but nowadays there is python so it shouldn't be such a problem.
This discussion caused me to look up info on it, and this source has some compelling reasons:
https://geoff.greer.fm/2015/01/15/why-neovim-is-better-than-...
For me personally, a good reason to switch seems to be the NeoVim team itself seems less hostile to new people and making changes. Of course stability is likely important to many people, so there may be many good reasons to stay with vim as other's have stated, but someone refusing an update because it uses ANSI C seems a bit much...
I disagree. NeoVIM is clearly worse, to me. It has zero benefits over proper vim and many massive downsides.
Lucky you elaborated and supported your opinion with facts.
I have no loyalty to vim, but https://github.com/neovim/neovim/pull/2856 means I can't trust neovim.
What about updating a file on the buffer that is changed on the disk means you cant trust them? (Especially since its an option that can be toggled?)
There's the change, and there's what the change says about the project. The change violates the principle that what is in the buffer is there because the user caused it to be there. Since it is a silent change to a principle that vi and its descendants have always followed, it can lead to data loss; the copy in the buffer may have been the only one. The fact that the change was apparently entirely uncontroversial means that neovim does not think through the implications of their changes and/or is not sufficiently concerned about data loss.
Disclaimer: I committed that change.
If you think the issue is important, you are free to report it; the project has reverted decisions like this when people have complained (most recently, the default value of the `mouse` setting).
On the other hand, considering how much time this had to be discussed, I would think that by and large this is not a mayor concern for users. This commit was made In June 2015, and the discussion about defaults goes as far back as essentially the beginnings of the project in 2014. We inherited this setting from sensible.vim (which many people consider, well, a very sensible minimal configuration), where the issue was discussed and dismissed back in 2013 (https://github.com/tpope/vim-sensible/issues/64). I think the argument there is convincing. Again, if you don't, please discuss it in the appropriate channels.
Ranked list of vim plugins http://vimawesome.com
This is one case where it feels a lot longer than that! I've used jot as primary editor on SGI and emacs sometimes and always when on Sun machines. Vi was always something I wasn't all that comfortable with. Then came about amiga where I've encountered Vim and thought to hell with it, why not. Ever since I've used Vim more and more and emacs less and less. In the meantime I've stopped programming as a full time job and I think in the last 8 years or so I've moved completely from emacs to Vim. With plugins I really don't see working any other way on longer things. For smaller, scratch type of crap I tend to dwell into sublime and experimenting with VSCode, but Vim is just, well, it's an editing experience. Fells like it has been around forever, probably due to vi.
I just wonder whether in 2042 we'll read about 50th anniversary of this masterpiece!
The original vi will hit that milestone in 2026.
I hope we will
I hope so too! Don't forget: http://www.vim.org/sponsor/
"Since Bram is back to a paid job the money will now (after March 2006) be used to help children in Uganda. This is the charity recommended by Vim's author. The money is used for a children centre in the south of Uganda, where AIDS has caused many victims. But at the same time donations increase Bram's motivation to keep working on Vim! "
I hope I will.
Congratulations Bram! 22 years ago I installed my first GNU/Linux distro and tried both emacs^ and Vim. I ended up liking Vim better and I've been using it ever since.
^ no disrespect to emacs though, it is also a great and venerable program!
I started using Vim on the very first release of Slackware, back in 1993, I think. I've been using it ever since. Thanks Bram!!!
Cool, the first distro I mentioned in my post was Slackware, in 1995. It came on cdrom with a book I picked up at the time. I think it took me a couple of months of using it to realize the vi I was using was elvis, a clone that Patrick shipped with Slackware by default. After reading about Vim and Bram I realized I had to install Vim separately.
I'm back to Slackware these days after moving away from Debian because, well there were reasons. Interestingly when I read this article this morning I realized that true to form Slackware is still using 7.4 so I downloaded the source and am compiling 8 this evening after work.
Thanks Bram indeed! :-)
My first distro was Slackware, and I bought it in 1995 as well. Mine came with a Unix book from O'Reilly. The only thing I remember about the book was a quote at the top of one of the chapters, "Dyslexics of the world, untie!"
I too used elvis for quite a while, until someone at the bank I worked for at the time introduced me to Vim. I've never met Bram, but I always feel a depth of appreciation when I see his name pop up in the editor window.
Yay! I've been using this for quite some time now. I build from the master branch on VIM's git repo for custom plugin support. There was a moment it had issues with the FishShell before this official release but that's fixed now.
I've also built this into a remote programming Docker image: https://hub.docker.com/r/danielpclark/ruby-pair/
I'm wondering how many folks are using g& command ;)
It works great considering that
:s//new_pattern/g
/old_patternI use Vim 8 (via MacVim) every day, but I'm definitely not at an advanced level!
I'd say the most advanced stuff I do is gqap, and performing substitutions via regex, either with a range or in visual mode.
I'd appreciate suggestions as to the best path to take, to move to a more advanced level of Vim 8. (Note I mention Vim 8 explicitly. Also, if extending my existing vimrc becomes a thing to do, I'd want to do it myself, learning what each not does!)
I found this book quite helpful in leveling up my Vim skills:
https://pragprog.com/book/dnvim2/practical-vim-second-editio...
I can also vouch for the Vim + tmux combination. PragProg has an excellent book on tmux too:
I used to use MacVim all the time, and have a healthy respect for the project. Might I also recommend a NeoVim/tmux combination? Personally, I can't think of a better development environment (unless you're coding in Java, but then you have bigger, sadder problems to deal with :) ).
Long-time vi[m] user, and always learning/amazement. This very morning I learned about the `-c` flag. So, `vim -c "set spell" my-misspelled-file.txt` starts up vim with a given setting.
That seems like more keystrokes than just entering "set spell" after it launches.
Vimscript now has lambdas and closures!
Also:
https://github.com/idanarye/vim-smile
Vim now has a ":smile" command :D
I just picked up this book on writing Vim plugins and scripts:
https://pragprog.com/book/bkviml/the-viml-primer
It has been good so far.
I wonder if we'll see software this timeless ever again.
Well, Visual Studio (via Visual C++) was launched 24 years ago, Photoshop is 26 years old, Word is 33 years old, Excel is 31 years old, Outlook is 23 years old, Total Commander is 23 years old, Eclipse and IntelliJ are 15 years old, etc.
I think we're in an age where distribution of software is so wide that the market leaders, especially if they're Open Source, last for decades.
You might as well include vi then, which now makes this software product 41 years old.