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 ;)
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³.
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
:noremap h <nop>
:noremap l <nop>
to keep them from the temptation of the nefarious h and l keys.
Lately I use
:no h ^
:no l $
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.
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.
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 ;-)
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.
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.
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.
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.
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.
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.
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.
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.
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).
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 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).
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.
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.
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.
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.
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
fi
Yep. 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.
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.
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.
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
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.
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"
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...
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.
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.
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.
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.
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.
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.
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.
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.
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...
> 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.
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.
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.
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.
" 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
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...
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.
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.
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.
"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! "
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!
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.
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 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 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.
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.
Please don't create many obscure throwaway accounts; we ban those. HN is a community. Anonymity is fine, but users should have some consistent identity that other users can relate to. Otherwise we may as well have no usernames and no community, and that would be an entirely different forum.
I think you have a fair point about offtopicness (and we've penalized that subthread for that reason), but the way you chose to make it—not just the multiple throwaways, but also the unsubstantive snark and (elsewhere) outright incivility—is not ok on this site.
The numbers tend to disagree with you. Unless you think that only hacker news users are on git... Given VIM is bundled with OSes, i would never expect neovim to take it place in usage numbers (unless OSes start adopting neovim as well)... but when it comes to actual interest, in just about every measurable aspect, neovim is coming out on top of developers who actually know about it.
Most devs I work with use it (if they use vim at all), I've seen it more than VIM lately at conferences as well. You give up nothing using it an gain a bit (and will gain much more as its further developed)
You just sound like a grumpy old man set in his ways, honestly.
No matter the discussion or behavior of other commenters—even if it's about editors!—it's never okay to be uncivil. This type of comment is uncalled for. The rest of your comment stands very well without it.
I don't consider people who use throw away accounts to spout crap and hide in cowardice to be real commenters... their feelings an opinions are worth the value of the throw away account they created to spout them.
That does not matter. Each of us on HN has a responsibility to treat each other with respect and civility. If you find you can't do that in a particular circumstance, refrain from commenting at all. Expressed another way, don't feed the trolls. Flag if you feel appropriate, and move on.
Vim hasn't been on GitHub as long as Neovim. Check out the mailing list, Reddit, basically anywhere but HN or GitHub. Neovim is a drop in the bucket. And since Vim has taken all the best features from Neovim (in less time -- Neovim hasn't released version 1 despite being crowd-funded for several years) this is really a Node-and-io.js situation. Vim is going to absorb Neovim.
Point taken in some cases, but a lot of those are misfeatures. The Lua API is not yet usable because they built a terminal emulator instead. If Vim had a terminal emulator, one would expect Neovim to remove that bloat. Not all Neovim additions are good ones.
"Vim hasn't been on GitHub as long as Neovim." -- which says a lot, considering its age... it speaks to one of the core problems, Bram's godlike grip over VIM.
On top of that, he only started to introduce these features AFTER neovim came and put the pressure on by doing it better... if neovim's approach wasn't better, why would he be implementing features he's previous said he wouldn't implement?
I have to assume you're either trolling or actually involved in the Neo vim project or something like that. Because there's no universe in which GitHub stars are an appropriate measure of popularity or interest.
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