Vim 8.0 is coming
github.com
github.com
What's interesting to me, and the reason I try to keep up to date with the latest changes for all four editors, is that it's been now, what, 25 years (?) since emacs and vim started "competing" and they still are. I guess we could be saying the same in 10 years about firefox and chrome, but it still is amazing in my opinion. It's amazing that so much work has been done to vim and emacs, and so many changes, so many users using them for different things. And there is still no clear winner. I'm not trying to start a discussion about the strenghts and weaknesses of each. Just expressing my appreciation.
Thank you for your great work, to everyone involved with vim and emacs, and more recently neovim and spacemacs. You are awesome.
Amazing, I was 1 year old when both were started. How many other software package has such longevity? Unix and its various guises?
That said, programing via editing text is a completely primitive method, and I hope things like http://unisonweb.org/ will replace it.
Even if one is not on-board the structured editing concept, with so much changing about the way we use computers and the software we run on time, the fact that our development methods have changed far less is quite anomalous and deserves critique.
If you're editing a lisp in emacs, you can already get halfway there with plugins like paredit or smartparens. You are pretty much editing the AST at that point.
Most of the UNIX userland is from then, though it has seen rewrites (including clean room ones) through the decades.
In the same sense, the emacs most people use is not the original one. Everyone uses GNU Emacs or Xemacs.
Not only in the sense that Vim is a clone of vi (with added stuff), but more specifically in that in lots of distros the vi command is just vim (with some special flags).
Old BSD vi today is, and has been for over a decade or so, dead.
Actually it does, as architectures, APIs, etc change, and if the software doesn't catch up, it can get impossible to run it, or it will need BC compatibility layers, to run 5-10-15 years down the line.
Not to mention big changes in how we use the software, e.g. the need to handle utf-8, which didn't exist in Bill Joy's time.
>It's not dead, it's finished. It's got all the features of the original vi, therefore mission accomplished.
Huh? "got all the features of the original vi"? We ARE talking about the original vi.
I have to politely but firmly disagree. Software rots if it's not being actively maintained.
Underlying API/ABI's get deprecated and eventually dropped, dependencies reach end-of-life and need to be replaced, and so on.
Take one program today and try to run it in 10 years, as is. I bet it won't work.
I'm talking of course, of any non-trivial piece of code. "Fizzbuzz" written in an interpreted language... it might even run if you're lucky.
(Edit: formatting)
But BSD vim (nvi) is maintained as part of the base systems of the BSDs, so it changes with system changes although it's in maintenance mode. E.g.:
So
> *Software doesn't need to be developed ad-aeternum to remain 'alive'.*
> Software doesn't need to be developed ad-aeternum to remain 'alive'.
(Not that this is an important issue.)
Edit: also, vi is not dead: www.archlinux.org/packages/core/x86_64/vi
No, it's a derivative project. However, in lots of distros, when one runs "vi" they are actually running "vim" (in vi standards mode).
Vim can be invoked to conform to the vi standard, although usually it only gets used that way when a vim user is on an unfamiliar machine.
Since I moved away from C++ into Java and .NET land, never felt the need to use them any longer.
And nowadays, with Qt Creator, Clion, xCode, AppCode and VS, I also don't feel the need of them when I need to go back to C++.
It is very good to know the basics from plain Vi, because there are still commercial UNIX systems without GNU tools installed, just bare bones installations.
So for me the question is why there are still people that enjoy working as if their computers are using a 25 year old developer experience.
The GUI paradigm is over 30 years old. People still stick to the mouse even though we've had ubiquitous touchscreens for almost a decade.
A good paradigm does not easily die.
Touch screens are not a 100% replacement for mice. They are an alternative, and for desktop/laptop PCs with vertical screens they are a non starter due to human physiology.
And they're not used as such. They are used as complimentary to keyboards.
On the other hand, mice-based GUIs ARE a 100% replacement for CLIs.
I had to use Xcode for a project and it gave me real anxiety. Weird things would go wrong and I had no idea how to fix them. The only sources of information were these horrible unanswered support threads on Apple's website.
Since Emacs is free, portable, and extensible, I can use it for lots of different things. And I know I have the freedom to change it any way I want. Of your examples, only Qt Creator has an open license.
Emacs is also a flagship of GNU. Xcode and Visual Studio are made for developing software in closed systems...
Xcode allows you to write and debug code for a specific compiler (like Clang or GCC). If you choose to use Emacs instead, you would typically use the same compiler as you'd use with Xcode, just a different way of editing and debugging your code. But whether or not you write software that is "closed" or "open" or "portable" or "platform specific" is a choice for the project, not the editor. Xcode is not for writing software in a closed system, it is for writing software, period. If you want to write software that is unique to OSX or iOS (using Apple APIs) you can do so more easily with Xcode, but a lot of my projects are command line tools that are used in any unix/linux variant, including OSX, and I choose to use Xcode.
My experience with Emacs/Spacemacs without having significant knowledge of lisp/elisp/Emacs debugging. I want to like Emacs, but my Vim environment feels so much more "solid".
It's completely awesome that you can change anything in emacs however you want but time and time again I realize that I'd rather have a rock solid editor with small api that let's you customize few things.
Secondly, working mainly as a sysadmin and only sometimes doing some development, I do far more with emacs than coding. I edit configuration files, look at log files, keep a "diary" using org-mode, use it for looking at directories with dired, I run a shell inside it (on Windows, eshell makes my life a lot easier). Having a single, consistent environment across many different languages, tasks, file formats and whatnot, with all my customizations working the same, is valuable to me.
If I had to code in Java, I would probably be using eclipse, too or JetBrains' Java IDE, and if I had to code in C#, I would most likely use Visual Studio, but I do not. So I stick with Emacs because it works well for me.
I use it to edit code simply because I feel at home in it, but I use very, very little of the functionality.
This really can't be overstated, or its value emphasized too strongly, and it goes a lot further than your simple statement makes clear.
There is literally nothing in Emacs whose source code is not trivially accessible from the editor itself, via the documentation attached to whatever functions or variables are related to the behavior of interest. (Even the C source code is accessible in this way, if you have it somewhere on your system and have told Emacs where to find it. Or, if you build from source, it will remember on its own.) You can access the documentation for anything, including keybindings, with a single command, and follow a hyperlink from there to the Emacs Lisp or C source in which it's implemented.
This reduces the mystery of why and how Emacs does what it does effectively to zero. If you don't understand why your last keystroke did what it did, you can find out. (If you're not sure what your last keystroke was, you can find that out too, because Emacs keeps track and will happily show you with M-x view-lossage.) If you don't understand how it did what it did, you can find that out, too. And if you want to modify what it does, there's a wide variety of ways you can do that, as well. Nothing in Emacs is inaccessible; nothing in Emacs is immutable. The only thing that can stop you, or even slow you down, from making Emacs exactly the tool you want it to be, is your own level of understanding and capability - and if you find it lacking, Emacs is there to help, and its community will cheerfully do likewise. (Oh, and the long-form manuals for everything in Emacs are built into Emacs, too.)
I've built several Emacs packages, and released a couple on MELPA to quiet but generally positive receptions - nothing particularly big or world-shattering, just small things to make other Emacs users' lives a little easier, or a little more fun. Almost everything I know about extending Emacs, I've been able to learn from Emacs itself, in the course of seven or so years of using Emacs. I can't think of another editor I've ever used, or even heard of, in which that would be possible. Considering the central position a programmer's primary editor occupies in her professional armamentarium, it's hard to imagine any other editor that'd do even half as much as Emacs to help me get my work done.
As you say, if I had to work in Java or C#, I'd probably find myself having to use Eclipse or IntelliJ or Visual Studio or what-have-you. It's not going too far to say that one reason I'm largely unwilling to work in those languages is because I wouldn't easily be able to do so in Emacs. That may strike some people as an astonishing assertion, and a foolish attitude toward choice of language. That's reasonable enough, but I misdoubt most experienced Emacs users would find themselves feeling much the same way.
My plan was to open up the manual and start reading, but maybe you found an article or tutorial that helped kickstart your org mode knowledge, so I thought I'd ask.
(Apologies if the question is a bit offtopic.)
Also remember org mode is as simple or as complex as you want it to be!
http://doc.norang.ca/org-mode.html
for me the initial "aha" moment was when I realized I could do an agenda window with multiple customizable horizontal blocks, so at a glance I can see deadlines, projects I am working on and so on
Adding to this something like being able to fulltext search across all my org files via org-occur-in-agenda-files is awesome too
I switched between Vim and Eclipse seamlessly, depending on what task I was trying to accomplish. Vim is better at plain text editing, Eclipse is better at navigating convoluted Java hierarchies or debugging Java code.
For me, those tools are not exclusive but complementary.
Or if you use IntelliJ Idea it also has a plugin for Vim
Those editing plugins usually don't really wrap vim so all you get is "vim-like editing" or "vi(m) functionality" which often lack some of my favorite vim shortcuts.
I find it much harder to muscle memorize the differences between the real vim and the "fake" one, so I prefer the tools that I use side-by-side to have different key bindings (for example, I use the Emacs key bindings in Eclipse).
Maybe check for updates? They do seem to update it semi-regularly - I think they fixed the number-gt command within the last 6 months or so.
For me it's the question, why it's so hard to understand that people have different likings without to downgrade them?
Everyone thinks that his/her decisions are the most sensible ones, but in most cases they aren't.
Because while everyone can have this or that preferences, personal taste is not the be all end all argument, except in the "it's a free country" way.
Whenever we want to assess the state of our tools, and what we need to make them better etc, we need to reach an agreement beyond "works for me" and personal taste.
Preferred tooling for reaching maximum productivity is an inherently personal thing - you may do your best in emacs, the other guy in vi, yet someone else in Sublime3 on Windows. Nobody is qualified to make broad sweeping judgments as to what works best for everyone.
A few try, and some inferences can be made to the lowest common denominator (see modern UI design practices), but if we're talking productivity for the super-literate user, then no, absolutely not.
For example, I might say that I'm super productive in IDE X, but I don't know for sure that I couldn't be more productive in IDE Y or Editor Z with various plugins. I haven't consulted any research in making my decision nor have I conducted any real research of my own.
I guess maybe it doesn't matter. If everyone is "happy", maybe that's good enough. But I see people struggling to do certain things in their environment of choice and that ends up having an effect on not just them but potentially their coworkers.
Unless they work for themselves, that "anyone" can be: colleagues, supervisors, bosses, teachers, and even clients, and also industry experts and seasoned pros telling best practices.
>Preferred tooling for reaching maximum productivity is an inherently personal thing - you may do your best in emacs, the other guy in vi, yet someone else in Sublime3 on Windows.
And yet tooling is regulated all the time in all kinds of companies.
And all kinds of people mistakenly think they are more productive with X, where they would be with Y. People make bad tooling decisions all the time. For those people it's perfectly OK for others to tell them what they should use.
The great thing about Vi (and I presume Emacs as well) is that you can get keybindings for just about any IDE. I use Visual Studio for intellisense, but I install VsVim which gives it 90% of the most commonly used features of Vim. XCode has XVim. IntelliJ products have IdeaVim. I've used them all, they're all great. It's nice to be able to feel instantly at home in any editor.
Personally, I use IDEs for the work they were made for. But if I just want to edit text or don't want to set up a project just for an "application" that consists of two or three scripts, I use a good and simple editor with syntax highlighting. Anything else would be like using a car to get from your kitchen to the living room.
Both command line development tools and IDEs require work to get the most out of them. I used to think command line tools were better because I was more in control, then I realised if I just spent the time learning what IDEs were doing on my behalf I would still have more or less the same amount of control, especially if the IDE is customisable (which the best ones are).
So with command line tools you have the option to customise your workflow from the ground up, but with IDEs you have the option to customise your workflow from the top down. Both have advantages.
I think this is the biggest draw for Emacs. It's a fully featured lisp development environment. If you want to change it, you just write lisp. If your IDE is free software, you can do the same thing, but they aren't always that easy to extend. Emacs, shell script, and the various tools are a set of APIs that you can code against. Most IDEs are geared towards giving you a UI interface to the functionality, not a programming API.
And that's fair, but not really what I'm after most of the time.
You can do that with Visual Studio too with Visual Studio Extensions. You can also manage extensions (including those from other users) with a built-in package manager, just like in Emacs.
Here's a Visual Studio Extensions tutorial if you're interested:
https://channel9.msdn.com/Shows/Visual-Studio-Toolbox/Buildi...
Compare that to couple of thousand commands available on the command line that do all sorts of things and that can be combined in useful, creative and often times unexpected ways. All that in addition to having a programmable command interpreter (i.e. the shell itself) that allows you to automated things you do often. Vim is often described as programming your text transformations, well command line is programming your workflow, but it is also more powerful because of the shear number of commands available.
Honestly, it's not a crime to like nice windows, y'know.
Something tells me instead of telling you what you can customise in good IDEs I should show you. With that in mind, tell me something I shouldn't be able to customise in Visual Studio and I'll show you how its done. To start this off, here's how to create custom keyboard shortcuts, as you can see it's very easy to do:
https://visualstudiomagazine.com/blogs/tool-tracker/2012/07/...
Take my first foray into vi, at its most basic level. I'm at a shell prompt, where I can use vi to edit multiple files, saving each one when I'm done with it and occasionally switching to another window to run something else, coming back when I need to edit more. But there's nothing storing my list of open files or buffers and where they are on my screen, my position in each file isn't saved; it's like vi expected me to spawn a new instance every five minutes.
When I tried emacs, which allows much more functionality inside the editor -- connecting to servers, databases, or hosting shells or debuggers -- it just made the problem worse. If I started a shell inside emacs before stopping the emacs process entirely, that shell won't be there when I get back and my files won't either. If I want to have a specific file on the right-hand side of my screen, emacs will forget where I put it. If I open a file in a new window, that file will be gone. If I want to have a file stand out by changing its background colour to a subtly-different hue, that will have changed back by the time I need to re-open my editor.
I don't like this idea; I don't want my editing environment to be some ephemeral process that's created when I start and gets destroyed when I'm finished. And while Vim has sessions and Emacs probably has three forms of saved states, they don't quite work: no saved window positions and sizes, no working with files you haven't given a name. I imagine that it's the same feeling you get when you read that something allows Emacs-like functionality: on a checklist, they might both have tick marks on each row, but when you try to use it, it doesn't work how you expect. I think that Emacs and Vim's command-line history have made its users used to this behaviour, spawning all sorts of tools to make configuring your environment easier instead of just trying to save the changes as they happen. I've seen plugins like CtrlP or projectile that enforce the idea that your environment shouldn't last, you can just set it up again each time. And that means you don't bother personalising your environment and putting things where you want them to be, because it's all going to be irretrievably gone if your computer crashes, so don't get attached. Alright, rant over.
This is useful for long running work, but more often it is not necessary. If you are just exploring the code base or making small edits here and there you don't really need persistent tmux session for that.
But yeah, that's pretty much my objection -- it's not a big one, and there's room in the world for more than one type of software. I'm aware of tmux, but it just shifts the problem from vim to tmux: once you need to upgrade tmux, or your OS, or your computer, everything you've set up gets lost, and I really don't want that to happen.
I'm also aware of things like teamocil, and I even used itermocil for a while. But it turns out that the kind of environment edits I like to make are ones that I just do, rather than ones I can specify in a config file then restart to set everything up again. For example, when you say:
> If you are just exploring the code base or making small edits here and there you don't really need persistent tmux session for that.
Coincidentally I do have a relevant example for that. Last week, when I was exploring the files that make up the zoneinfo database, I put the files that I needed to keep referring to (of which there were like 5) to the side, knowing full well that they wouldn't go away. Then they just stayed there for a while as I got distracted with other stuff. This week, when I had to return to it, they're still there; and all the files from the other projects I'm working on are all in their positions, too, ready for when I switch back next week, surviving through a system restart and an editor upgrade.
Do not close vim.
I keep a main vim instance which has different buffers open. These buffers have their own history, e.g. undo-tree, etc. And keep in mind, that it takes time to get adjusted to vim, otherwise one gets overwhelmed quite quickly. E.g. I suggest to ignore windows and tabs at the beginning and get comfortable with buffers first (e.g. mostly I only use buffers).
However, as someone once said: "The universe tends toward maximum irony. Don't push it." If you don't close vim and keep it open for weeks, then all your environment changes are going to keep on building up, only for you to lose everything the next time you need to restart your system, or upgrade your editor or terminal, or your OS crashes, or there's a power failure, or your computer catches fire.
Which editor are you used to using that does, though? I ask because I'd like to experiment with it a little and see what it does and, to the extent possible, how it does so, because that seems like a useful capability for Emacs to have, and one of the nice things about Emacs is that it offers a programming environment flexible enough to support most other editors' "hey, neat" capabilities - the Sublime minimap, for instance.
I there an editor/IDE you use that gives you the persistence?
Most modern IDEs also have a notion of session.
Emacs is not a 25 year old developer experience, however. It's got an integrated package manager; responsive full-project text search (helm + your chosen grep tool) and path search (helm + projectile); good to excellent support for dynamic languages in particular (there's a nice synergy with e.g. ruby/pry).
It's not as strong with statically typed languages. There's no project-wide full-fat high fidelity symbol database support. There are a variety of projects to try and implement things along those lines (semantic etc.), but Emacs Lisp isn't the right tool to get the necessary level of performance. I'd love to see Emacs on Guile come to fruition; the ability to escape out into a language with less freedom to mutate scope (and thus optimize) would be a Good Thing.
I use Emacs (on Linux) to write JS, CoffeeScript, Ruby and C++; I use Eclipse to work with Java (though I'm considering switching to IntelliJ). Working with Java in Emacs is an exercise in pain, particularly since things like wildcard imports are frowned upon in the Java world. Eclimd is not good or reliable enough when used from Eclipse. Eclipse is deeply unpleasant to use compared to Emacs, which I'm able to easily customize to my preferences.
- You can just live in it. You don't have to leave. I watch TV using dired to run mpv and use org-mode for my todo list. It's all right there.
- Once you get used to one set of keyboard shortcuts, you can harness an enormous amount of power throughout the whole environment. This is true in some IDEs too, but IDEs don't usually offer
- Rust. Rust is actually one of the main reasons I started picking up some Emacs. There are no good Rust IDEs. There's crappy VS and Eclipse plugins. There's Atom plugins, but Atom freezes randomly when running code with Cargo and the DPI scaling still doesn't work properly on Windows. SublimeText was the only thing I could find that worked, and while it worked I wasn't willing to commit $70 to buying a text editor. Then I tried Emacs and it works absolutely beautifully.
- Emacs has really take advantage of the GUI paradigm too, check out the minimap: https://www.emacswiki.org/emacs/MiniMap It's not just some outdated console application that no one uses anymore.
- You don't need a different IDE for when you're writing python vs C++ vs Javascript. There's no switching. Just open whatever you want in that permanent emacs session you have running.
- Most if not all IDE features are actually available easily via plugins, yes, there's a little configuration involved but most of the time it's not too bad. And I'm a tinkerer so I really don't mind.
Overall, IDEs are great if you just want to sit down and code without the tinkering. But if you're willing to put the work in, I think you can get much more comfortable in something like Emacs where you have deep flexibility and access to most (if not all) of the same features once they're set up. I can definitely see the appeal. Especially of really unique stuff like org-mode that you just can't get anywhere else.
Only recently some competition has emerged, from Intellij.
> Xcode is 13 years old.
Because for a lot of tasks using the mouse is garbage compared to the speed you can get using the keyboard.
For example, these are some of my favorites:
https://valloric.github.io/YouCompleteMe/ - Code completion for C/C++ and other languages
https://github.com/ctrlpvim/ctrlp.vim - TextMate style ctrl+p fuzzy file finder
https://github.com/scrooloose/nerdtree - Tree explorer plugin for browsing files
https://github.com/vim-airline/vim-airline - Customizable status line for showing all kinds of useful info about currently edited file
https://github.com/tpope/vim-fugitive - Git wrapper that works together with airline
https://github.com/mhinz/vim-startify - Shows your most recently edited files and favorite files on the start screen
https://github.com/tpope/vim-abolish - Smart text replacement, easily replace eg. getColor, GetColor -> getTransparency, GetColor and so on
And this combined with the fact that I can do all of this from the tip of my fingers, without having to touch the mouse, with high customizable commands that go into my muscle memory, there is no substitute for VIM for me.
I've worked with Eclipse, Xcode, Visual Studio. They have some pretty nice features, like interactive debugging that are hard to replicate with Vim, but I'm more of a "print debug message" kind of guy anyway, so that doesn't bother me.
The biggest hinderance with Visual UIs is that I have to use the mouse, and that sucks. So much faster to do text selection, copying, replacement, renaming and so on straight from the keyboard, once you get used to it.
I'm still discovering active new ways to customize VIM after over 15 years of using it.
I also think that interactive debugging of any kind is much faster than printing debug messages most of the time. Even if it's just something like Ruby Pry, where you have a command line REPL while stopped on the breakpoint, it feels like a huge time saver when you can be stopped at a particular point and are free to check any variable and step whenever you want. Granted for some cases, like production web sites, there's no alternative to writing debug messages and trying to figure out what happened through them.
But I think there is this huuuge group of people that enjoy the integrations. Xcode can't do much besides be a pretty GUI for clang and lldb. If that's enough for a developer, then Xcode is perfect. If a user likes some more customization and integration than just that, then they're out of luck. For Xcode, there are some very basic plugins, used by people who just need Xcode + some small adjustment (eg. me wanting some vi bindings). On the other hand, for vim and emacs, there are plugins for anything and everything, from irc to mail to ordering salads for launch [0]. When a user is comfortable enough and wants to live inside their editor, then I don't think vim and emacs can be beat by any other modern editor/IDE.
Maybe atom will be the new emacs in a few years.. who knows :)
Yes, they still keep their keybindings, which don't match the common "modern" editors, but honestly, that's a big part of what people like about them.
I use Vim for several reasons: First, it's language neutral which is good if you use many different languages. Second, I touch-type and like to avoid as much as possible the use of the mouse/trackpad. And finally, it's available everywhere.
But yes, I agree it has its limitations. A lot can be done with plugins, but it then becomes more fragile and a mess to maintain. I think it still makes sense to use Vim (+ a few light-weight plugins) for smaller projects .
Other than that, my plugin selection mostly includes plugins that add specific motions (EasyMotion), commands (vim-surround), or behavior (detectindent.vim).
On the other hand, I absolutely despise plugins that claim to turn Vim into an IDE for $language. These tend to be bloated as fuck.
Another reason is because I conciously have decided that gnu and gpl are what I want to run whenever possible, which also affects my other tool choices, eg, screen vs tmux.
Using a SmallTalk system was a somewhat different experience. Now that was integrated.
The VM ( or image) is the run time and the editor at the same time. The level of integration and introspection made the whole thing very powerfull and inspired other IDEs to have this features, which without the software development could have been very slow.
Existing responses already covered a lot of things, but the simple answer is: most of us don't.
The state of these editors and tools 25 years ago, while largely the same, is still very different: there are still major improvements, many new packages, etc.
Could I work on a 25-year-old system? Sure, and it'd be largely the same, but it'd be pretty uncomfortable; those subtleties matter a great deal. ;) Especially in my editors (both Emacs and Vim), and on the command line (both tools and even readline).
Every so often, I come across a cool open-source project that I would like to build and tinker with, only to find that it can only be compiled if the Visual Studio solution file or XCode project file from the repo is used.
Or let's say, it could be compiled probably, but replicating all the logic hidden inside the solution/project is ridiculous.
That's not to say that you can't have the best of both worlds. For example, CMake can generate both Makefiles and VS solutions.
I use MacVim and my .vimrc file follows me around wherever I go. My experience is great in my editor because the few minutes I invested here and there have huge payoffs over time whereas most IDEs plateau.
Minor nit in support of parent comment: no it doesn't, you have to copy or sync it around yourself.
Atom is a great example of an editor that is aware of the internet existing. Vim, while my daily driver, is not.
Because i develop on very expensive hardware on a different continent. I also end up with a decent mental model of my code.
The carbon footprint is much nicer.
A: Rarely.
There's deep muscle memory involved.
It's very hard to contemplate switching and, once you do, it takes a lot of commitment before you can cross the line where you are more productive than before. Like learning a new language.
So people tend to stick with the one they learn first and reverse-engineer arguments for its superiority.
Emacs on the "platform" (superior scripting language (elisp), better external process management, better instrumentation).
Vim on the modal-editing interface: you can find it in nearly all editors (and even browsers) nowadays.
A combination of the two would be awesome, correction "is" awesome: http://spacemacs.org
https://github.com/jimmay5469/vim-spacemacs https://github.com/sunaku/vim-shortcut https://github.com/sthysel/vim-spacemacs
This said it is exciting to see vim being updated, I use vim quite a bit if I am ssh-ing places and the more functionality the better
Are both great tools but with a completely different mentality and people will prefer one to the other depending on so many factor that the quality of such tools is not even so influencing.
On the other hand there is not so much distinction between Firefox and Chrome and there is going to be a winner as long as the browser are so similar to each other.
You and I are the winners. I've used both Emacs and vi (not vim) for a long time, and switched "major focus" from vi -> Emacs -> vi. That they're such venerable tools and still getting bug fixes, improvements or serious active development is amazing. Long live Emacs. Long live vi.
I have no plans to run Neovim in the near future, but I'm already profiting from it. Kudos to Tarruda and friends.
That's pretty optimistic considering Firefox's current marketshare. Based on its momentum I'd say in 10 years, at best, I expect it to be where Opera was before it became a Chromium fork.
For now Firefox does things better than Chrome but I don't expect them to keep up when it becomes a community project. It'll be like using Opera used to be.
http://www.theregister.co.uk/2016/04/11/future_of_firefox_is...
But since that was published, another article was published:
http://www.theinquirer.net/inquirer/news/2454466/mozilla-is-...
So there was no announcement, just some experiments.
Shackled by my past...
Wow! This is huge. So many interesting features landing on Vim 8.0.
I've used (an older version of) Vim on huge 100MB+ files and never thought it to be slow at all. In fact I don't think I've ever experienced any lag with Vim. I suspect you won't find this new version any faster.
Async I/O is not about disk I/O, but communication with other programs.
I recently switched to NeoVim and it really _does_ make a world of difference, saving is a whole lot faster when git-diff can be performed asynchronously and the ability to scan directories in the background makes fuzzy searching of files a lot faster.
I don't keep myself much up to date on these things, but wasn't this one of the main new features in NeoVim? (then code cleanup, then more language to script in)
I've been a happy neovim user for a few months now, but I'm still glad to see that vim is keeping itself up to date.
On the one hand, great to see such a huge release for Vim that brings so many features people have been begging for. Especially Async IO and JSON.
On the other hand, I hope Vim just become more stable and performant while not introducing new features. At the same time, I hope more development could go into NeoVim, and more people could start using it and writing plugins (not in Vimscript) for it. I want Vim to be my backup editor -- always there and reliable, and Neovim my working gear -- great features, joy to use, could have a few bugs that don't affect my workflow too much and are a natural result of fast-paced development.
I know this sounds really unfair to Vim devs. I'm sorry! I really appreciate the works you've done to make Vim amazing. But I feel for me, I just want to spend 95% of my time on one editor. Now I'm on the NeoVim boat, I feel like having completely switched my workflow to Atom from ST3, and just learned ST3 is going open source.
What I'm still holding out for is an _embeddable_ NeoVim. The thing I really don't like about IDEs is that I love my Vim configuration but I never get to actually use the damn thing since I do most of my work in an IDE. Now imagine if the IDE could actually just embed NeoVim, and I could use my Vimrc as-is with all the plugins (now managed natively). I know they already have Electron-based UIs for NeoVim, and Electron-based IDEs, so hopefully it's just a matter of time.
That said, does this actually put NeoVim _behind_ in terms of feature parity?
I'm pretty sure SolidOak just embeds neovim: https://github.com/oakes/SolidOak
[1] https://github.com/neovim/neovim/wiki/Related-projects#gui-p... [2] https://neovim.io/doc/user/msgpack_rpc.html
He means that using one editor he loves (vim/st3), then switching to a replacement (neovim/atom), and then learning that the format editor gets better (vim gets async, st3 goes open source), brings "confusion" on the choices made. It's hypothetical.
All of the new features of Vim are super nice, but I'll still primarily use it for the terseness of its editing UX.
The startup time compared to vim is painful, and the daemon mode on OS X appears not to work. For project work I use it heavily, but for quick edits still fall back to vim. I've yet to test whether neovim gets rid of the UI blocking that made vim so unusable for me though.
Now I'm somewhat the opposite, I expect everything else to have Emacs bindings, except when I'm directly editing code.
This is a little surprising since the latest version of Emacs still supports MS-DOS[1]. If anything, you'd expect Vim to be the smaller and faster choice but it seems this isn't the case anymore...
Then again, I don't really understand the culture of all the customisation/plugins/etc. around text editors; part of the reason why I originally chose Vi(m) over Emacs on Unix-like platforms is that it's small and simple, and perhaps I don't expect or need much from a text editor in the first place since I used MS-DOS Edit[2] as my main text editor for many years and on Windows I'm perfectly content to use Notepad. I use the CLI for more advanced text manipulation.
1) small, basic install of (neo)vim for most users 2) totally separate extensions for those who need them without making the core app harder to test
> it's small and simple
Allowing plugins doesn't make the app any more difficult to use. And, of course, one thing some plugins do is make stuff easier than stock vim. IE rather than going:
:e ../../src/java/blah.java you could use one of the many fuzzy searc plugins and do something like: <C-p> sjablja (ie just typing some of the letters from any part of the path and file name as long as it's in the correct order).
> I don't expect or need much from a text editor in the > first place
It's primarily a programmers editor, replacing for many people any IDE at all, so it's nice to be able to select a word and press a key and have that file open; jump between viewports on multiple files on multiple tabs; have word completion.
None of what I've described is some rare edge case.
One thing I use vim for is to get the results of grepping thousands of source code files, then trimming down the results using "remove lines matching this", "remove lines not matching this", or turning lists of filenames into dos or bash commands. Sure, you can do all this with bash but I don't know all the commands anything like as well as I know how to do this sort of stuff with recordings or regex within vim.
Vim also doesn't run on OS/2 and other platforms, though the Makefiles have not yet been removed.
I also remember that we had a problem with transferring the resulting data for analysis, because the physics department had just been equipped with new PCs that did not have floppy drives anymore.
Is this going to replace pathogen?
The only other feature request I have is expanded features for window drawing for plugin makers. I want to be able to draw over a buffer without editing the text.
If you've ever used jedi-vim, you'll see the function's signature appear above the line you're editing. What a lot of people don't realize is that is actually modifying the file and saving the prior contents of that line in another process. If you kill vim and recover from the swapfile, that line is gone... It's a dirty hack for a feature that people want-- scratch buffers suck for this purpose.
I'd be happy with either having function signatures formally tacked onto omnicompletion, letting omnicompletion providers do function signatures cleanly, or having arbitrary text-display over a buffer as a standalone feature, phasing out omnicompletion pumenu.c for this generic interface-- and omnicomplete would have to be rewritten to use this interface.
Now, from what I can understand, Neovim only has two advantages, a cleaner code trough re-writing (it's debatable if that's really an advantage) and the ability of using other languages for plugins (which seems clearly and advantage due to the lacking features of VimScript).
All in all, it's a nice step forward for Vim.
It's a very overlooked feature that has a great positive impact in usability. Been talking in a bug thread spacemacs about this same problem for months and there is still no solution to be seen.
call High#Light("Comment", "italic", "bg", "#003300")
(Source: Somewhere in :help, but unfortunately I can't find it right now.)
I can do that in Vim nicely after hacking the console colors, and Neovim without having to care about the colors and in Emacs it remains impossible.
I tried fzf after thinking it was just a vim plugin and the install-process immediately drove me away.
Don't edit my dotfiles and change my $PATH with your installer. That shouldn't ever have to be said.
</rant>
./install --no-update-rc
:terminal in Neovim works very well.
> if Emacs and Vim just had correct color support in the console
Neovim supports true color in terminals that support it.
Before neovim: Asyncronous operations? "Absolutely impossible"
After neovim: Asynchronous operations? "Why, of course, here, with a cherry on top"
I definitely would not suggest to "just keep going". Improvement is slow by yourself and the things that make a major impact are not in your repertoire because you didn't even think they exist or that you could use them that way. Find people like Derek, who are admired by the vim community, then study their works. It's not about mimicing them but about understanding how they solve problems and thereby increasing your thought limits. Then you go and build your own skills with your new horizons as new limits (which is the lonely and hard part, but necessary).
Once you are certainly above the threshold of intermediacy this method becomes effective. Beginners should follow tutorials. Experts have no other choice but study other experts. In intermediate level you have the luxury to get value from nearly all methods (basic courses, tutorials, videos, discussions, studying masters are the ones I know about).
example of my vimimprove.md:
- 5 deleting word while curser is in the middle of that word
- 2 insert parantesis around the word im on
....
when something reaches 10, I google it and write it on a note. Then the first thing I do in the morning is doing that thing 10 times. Before I leave work, I do it again. And of coarse if you use it while working you might just have it in your muscles or you look at your little note. Then after a while your finger get that ninja stile of doing stuff you brain just things about.
Like ying and yang
`daw` and `diw` deletes a whole word (unlike `dw` which only deletes forward). They differ in what they do with whitespace; `aw` also trims trailing whitespace (or leading whitespace if there's no trailing) while `iw` leaves the whitespace alone. These two are text objects that can be combined with other commands and quantifiers, so that `yaw` copies a word without deleting it, or `d2aw` deletes two words.
Wrapping in parens requires the vim-surround plugin, but with that installed you can do `ysaw(` and `ysaw)` to wrap in parens (also works with brackets and curlies and such), either with spaces inside the parens (the former) or snugly around the word (the latter).
:help text-objects
Text Objects are really the best thing about vim after the command grammar itself.
> insert parantesis around the word im on
Install surround.vim and add the following to your .vimrc (I think s duplicates c too closely for the prime keyboard position. Therefore, s is for surround):
nmap s ysi
nmap S ysa
nmap s$ ys$
nmap sv gvs
Get a pdf of it here: http://www.eandem.co.uk/mrw/vim/usr_doc/.
This was by far the most effective way I went from intermediate to advanced. The key is that you can see the key sequence of how other people got to their solutions. Then you can judge whether those solutions are just a one-off niche use case or if you can put it in your tool belt of VIM dominance.
Practical Vim is a great book for intermediate/advanced users. I've been a Vim user for at least 15 years and I enjoyed it a lot.
https://github.com/vim/vim/commits/master
And most of them don't have a name.
I am surprised that nobody mentioned this: Bram (Vim's author) was in the beginning very much against async in Vim and this was one of the main reasons that the NeoVim fork started.
6 Months later Bram comes up with tons of features and one which he heavily opposed.
Anyone know why this change of mind? The fear of Neovim or did I miss anything?
Of course it would be better to have both. But don't dismiss code that survived the withering infernos of real world use. All those edge hacks are there because they probably need to be.
I work on Python apps all day and am constantly running she'll commands, interacting with git, starting / stopping services. Along with tmux, I can switch projects incredibly fast without having to wait for an IDE to load.
If you don't interact with text most of the day, I am not sure Vim is worth the curve.
Sure, it is a learning curve, but once you get the basic idea that it's a sort of language for manipulating text, then the rest is just adding to that.
For example, once you know that "d" is the verb to "delete" and that verbs can take nouns (like "w" for "word") then "dw" deletes a word. Now you can learn new nouns and apply to all the verbs you already know. Same for motions G is the motion to move to the bottom of the file, "dG" will delete from the cursor to the bottom of the file.
Anyway, far smarter people than me have made some great introductions. I would recommend the following:
1. go through "vimtutor" 2. Look at vimcasts 3. In a while, "Practical Vim" is a very nice little book.
Good luck :)
The reason I switched was pain in my fingers. I minimised the keystrokes I need in order to get my work done. After a two weeks, the pain in my fingers disappeared.
One example of such efficiency: to delete everything within an HTML tag, you just type: dit - delete-in-tag, not even that hard to remember.
vim is complicated, but if you spend just an hour learning it's capabilities, your productivity will improve. vim is crazy(/overly?) complex though, so do not think you are alone.
I've only toyed with emacs, but based on that, I don't think emacs' idea of keyboard "chords" is as good a fit as vi(m). With standard keybindings, it also puts a strain on my wrists.
Modal editing and the "edit language"[1] (verbs, nouns, modifiers (and motions), like dw=delete word, dd/dl=delete line, d$=delete from cursor to end-of-line, dG (delete to endo-of-file, where gg/G is motion for moving to top/bottom of file respectively), ciw()<ESC>P=change inner word (cut word under cursor to buffer), add "()", escape out of insert mode, paste word between "()"). These look cryptic, but quickly starts to feel quite natural and intuitive.
My impression is that Emacs' Evil-mode has evolved quite a lot lately, and allows one to combine the best of both: a much better programming language (scheme dialect) for customization, with modal editing and vi(m) key bindings. But I've yet to play with it.
If you don't mind using the mouse, you might also want to look at ACME[2] - it's a bit more exotic, and unfortunately hasn't gotten as much support as VIM/Emacs.
The creator of Vim, Mjolnar, has a great video on "7 Habits For Effective Text Editing 2.0":
https://www.youtube.com/watch?v=p6K4iIMlouI
I think the idea is very powerful: aim for incremental improvement in your workflow. You don't have to use vim to do that, but you certainly can use vim for that. Another editor that might be worth a look if you're not already familiar with vim, is: https://github.com/mawww/kakoune
The main argument for Neovim/vim/Emacs over other "smaller" editors would be the plugin eco-system. I have a theory though, that beginners tend to start out with a lot of plugins, and then gradually trim down, as they realize the power that lies within the editor itself.
Still, for vim, you will probably want a plugin manager (well, maybe not now with vim 8 supporting that out of the box :-), and depending on what you're writing, some integration with a tag tools, like cscope, perhaps a search-tool like Ag/The silver searcher: https://github.com/rking/ag.vim#readme
As for plugin manager, I'm personally in the process of moving - I'd suggest looking at Vundle and/or vim-plug.
Finally, you can generally count on any unix-like system to have some form of vi(m) installed -- I'm not sure I really see that as such an important point, but does make it easier to edit stuff on a server with only ssh open to the world. But that stuff you're editing should probably be in a VCS, and use some kind of automated push to land on the server anyway! :-)
[1] http://yanpritzker.com/2011/12/16/learn-to-speak-vim-verbs-n...
"A Tour of the Acme Editor", by Russ Cox [2] https://www.youtube.com/watch?v=dP1xVpMPn8M
Starting up a competing project has a huge cost. Once started, it's overwhelmingly better for the world for the competitors to continue[1], so that they can continue to make each other accountable.
[1] Unless one of the competitors is able to subsume the other. Like EGCS subsumed GCC back in the early 2000s. Total victory is a valid emergent outcome of competition, not somebody deciding what 'should' happen.
https://github.com/melling/EditorNotes/blob/master/vim.org
To me it feels like the vim key bindings are more efficient for programmers. No one has ever done a scientific comparison, and it always seems to end in a religious war, but we should do a better job of evaluating our tools. Then hopefully, we can improve them.
For me personally, I can't use the mouse much, or my carpal tunnel comes back quickly. So I need a keyboard-only workflow. And I'm happy with vim.
"A Tour of the Acme Editor" by Russ Cox https://www.youtube.com/watch?v=dP1xVpMPn8M
So to really compare efficiency of, say, Emacs vs. vim, you will first need to find two users. One who is as proficient in Emacs as the other is in vim. Good luck with that. :)
I worked on the first release of AIX for IBM. Their lawyers took a couple of years to get comfortable with the Emacs license so I switched to using vi for two or three years. (At one point I had to demo a Lisp system running on AIX at at AAAI conference and I could barely work the built in emacs-based editor.) Eventually, I was able to switch back to Emacs on AIX.
My own preference is Emacs for it's breadth of features and its customizations, but I still miss the feeling of speed that I had while navigating source code with Vi or Vim. I still toy with Vim every so often, but I've forgotten so much that I just plod along. Spacemacs is currently on my system, but I usually prefer my own set of customizations and just stick with Emacs and its ordinary bindings. Nevertheless, Spacemacs is an work of genius.
I'd encourage everyone to learn basic vi (say what's taught in the tutorial), it's everywhere. After that, IMHO, either of these ancient editors is wonderful and worth adopting.
Someday I'm hoping that a new Emacs will be developed built along the lines of Neovim. Digging into the internals of a big Emacs package is pretty painful for me when all I am doing is trying to fix some aspect of my editing experience (see https://xkcd.com/1205/). I'd like a more modern extension language than elisp. While I'm dreaming, someone please rewrite LaTeX to use a real programming language instead of its Turing complete macro language.
Remember to donate to uganda guys it's the only thing Bram asks for in return for this software.
https://github.com/vim/vim/blob/master/runtime/doc/version8....
This will be quite a long journey I think - an exciting one.
The other thing is that I think Vim and NeoVim will diverge at a faster rate now. They'll soon be way too different to be related. So NeoVim won't be a "nicer"/asynchronous/opinionated Vim anymore. But it's own alternative.
It's interesting that ido-mode doesn't first create a cache, and the built-in functionality available via elisp seems to be sufficient for speedy performance.
Also is there one simple key combination to [un]comment a line or a selected block?
I found out how to do many simple operations with this ancient tool, what can be really fun if you have nothing else funny in life (too many people have no other sources of fun, really) - but I am still not convinced. Many operations that are a no-brainer in e.g. geany take serious planning and studying in vim - this is absurd.
I fear that we are wasting many potentially good programmers because they accept the primitivism and stupid limitations of vim as something "cool" and will never again in their lives be able to program a user-friendly GUI because their brain is "vimed out". Maybe that is one of the reasons why we still have so much really bad software.
Once I was totally impressed by programmers, they were the wizards of today, superbrains, uber-humans. Then I learned programming and understood how many uncreative and cognitively limited people are just repeating stuff that somebody else has told them, without ever asking. Basically the typical obey-guy, the perfect follower who never questions any order will be that kind of a good programmer, reading manuals and getting happy that he is able to reproduce - there is no creative moment here. Only very few of them are part of a creative elite that actually brings new ideas to life - most of them are totally dumb rat soldiers just following the orders. This is the reason why such ultra-primitive tools like vim still exist.
For commenting and uncommenting you can check the NerdCommenter plugin.
If you're running vim in a terminal, there is an option to add native clipboard support to your yank registers. If you use vim under OS X and have installed it with brew, it will be added automatically. To check whether your current vim installation has clipboard support, try running `vim --version | grep +clipboard`.
You might also find this to be helpful: http://vimcasts.org/blog/2013/11/getting-vim-with-clipboard-...
Furthermore, Vim needs to be setup and is configurable because it existed before many computer usage patterns had been standardized that we take for granted now (e.g., Vim's cut and paste system is different than any current big name operating systems).
But the very fact that Vim pre-dates these paradigms, and continues to be used despite the extra work it requires to get past that, this very fact is what makes it more likely that you'll be able to continue using it indefinitely. I.e., Vim will survive the next paradigm shift, because it survived the last one.
If you really want to be careful about investing in learning a tool, the ones you should be careful about are the ones that have not survived a paradigm shift yet.
(Photoshop is great example of a dangerous skill investment in my opinion, Photoshop takes an extraordinary amount of muscle memory to use effectively and it hasn't yet survived a paradigm shift. Those skills look poised to become completely obselete by touch-based design tools soon, 5-10 years from now. Not saying I have an better idea, because Photoshop is still probably the best tool for doing that type of work, but just plan on throwing everything you learn away.)
It is true that vim is not optimized for ease of use, especially for newcomers, and also has some problems that are considered to be solved for any decent GUI framework. But I don't see how this can affect creativity. Does carbon fiber guitar somehow magically make you more creative? Similarly, does plain old guitar made of wood hinder your creativity? I don't think so.
set clipboard=unnamed
"*y<movement>
"*p[And not all programmers use Vim or Emacs. Programmers are people, and like all people have differing opinions.]
:set nonumber
vnoremap <C-c> "+ySelect mode is used by snippet engines mostly, and you don't want this mapping to affect select mode.