@romainl Not really. ftplugins don't have source guards since they get loaded for every buffer of that filetype, so ~/.vim/ftplugin/foo.vim is loaded first and can be overridden by $VIMRUNTIME/ftplugin/foo.vim. Then ~/.vim/after/ftplugin/foo.vim is loaded and can override anything done by $VIMRUNTIME/ftplugin/foo.vim.
@Carpetsmoker I don't think the autocompletion tag changes are accurate. Vim doesn't have autocompletion except through plugins that trigger completion when you press relevant keys. Tags like ins-completion (which you replaced with autocompletion) and cmdline-completion seem better since they describe what type of completion is being used and map to the relevant help topics.
Eh, there are a lot of cases where integration with an external tool is useful, and that's actually one of the more difficult things to do. NeoVim has made that a little easier because of the async jobs
Sure, but they don't fix the problem. They just provide some more capabilities. Even plugins using those languages will (depending on what they're doing) need to resort to telling Vim to send key presses
Yeah, vimscript is really just an extension of the commands you're typically using anyway. Emacs is built on top of elisp and everything is a function. Even the default key bindings are just bindings to functions. That's one of the big advantages on Emacs, IMO, over Vim since a lot of vim scripting relies on sending key sequences. Newbies have to learn the hard way how to avoid user-configured key bindings rather than just being able to call explicit functionality.
Yeah, people I've worked with always say it's hard to code Java without using an IDE, but I did that just fine in Vim without any specific Java plugins
Framing it as one editor vs another isn't useful. It's obvious that many applications don't support modes outright, so emacs-like (really readline) bindings are pretty common.
I don't see how Emacs fails the usability contest. Both editors are comparably powerful tools, but which draws different people for different reasons. I happen to use both.
@muru I've been meaning to discuss with the broader Debian developer community the right way to handle dynamically loaded libraries to at least avoid point 2 in my post. That would get us closer to where I would feel comfortable building with Python2 & Python3.
@muru It needs rebuilding to be able to use the different versions of the library, yes. The only reason there are different versions on the same system is that they're ABI/API incompatible.
Effort? Not much, but that's extra archive space and build time. Also, why shouldn't I then do the same thing for the different lua, ruby, and tcl versions that are in the archive? People shouldn't need to choose which version of installed Vim to run in order to have a plugin work.
