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
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.
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.
Is that also the origin of '^' being start of line in a regex?
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 ;-)
So true. So many capital letters typed and deleted.
Here's a write up with nice pictures.
http://www.catonmat.net/blog/why-vim-uses-hjkl-as-arrow-keys...
I'll have to try this for a week.
:ino kj <Esc>
:ino <Esc> <Nop>
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." :)
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).
• 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
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.
These days it's vim-sensible,vim-go, syntastic and the base16 themes.
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.
It's better to start from something that already solves code editing problems and then customize it or even rewrite rc from scratch.
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 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.
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
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.
There is a learning curve with any tool.
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 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"
Then if you do want auto-updates you just call "PlugUpdate" in your .vimrc
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 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.
Aaaaand now I want to switch to neovim.
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 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...
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.
> 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.
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.
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.
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.
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?
It's not a knock against neovim, but I just hope they can keep things going.
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.
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
endifNever 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.
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...
"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! "
^ no disrespect to emacs though, it is also a great and venerable program!
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! :-)
I've also built this into a remote programming Docker image: https://hub.docker.com/r/danielpclark/ruby-pair/
It works great considering that
:s//new_pattern/g
/old_patternI'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!)
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:
Also:
https://github.com/idanarye/vim-smile
Vim now has a ":smile" command :D
https://pragprog.com/book/bkviml/the-viml-primer
It has been good so far.
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.