Vim 8.0 is coming | Hacker News Reader

Vim 8.0 is coming

github.com

649 pointsmrzool412 comments

I have vim, neovim and emacs (and spacemacs) installed. Right now I'm trying to get into emacs a bit more.

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.

You'd think based on how fast software 'evolves' one of them has grown highly venomous, and the other extremely poison resistant :P

I became an heavy Emacs user as I could not find the comfort of Borland IDEs in UNIX, as I started to use it.

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.

Xcode is 13 years old. Visual Studio is 19 years old. Why would people use them? Because they have evolved, just like Vim & Emacs.

Well, for various reasons both of them don't really have any competition. Xcode, especially, is the IE6 of Mac coding.

Only recently some competition has emerged, from Intellij.

I can't say anything about Xcode, but I can say that VS hasn't stagnated in that way, every new release seems to bring something worth having.

Is there a CLI mode?

You can perform a number of the functions of VS from the CLI. Were you interested in editing text from the CLI or was there something else you had in mind?

  > Xcode is 13 years old.

27 if you count before Apple bought it (NeXTSTEP Project Builder / Interface Builder).

True. I think VS is also based on Microsoft's earlier language specific IDEs, making it probably at least 25 years old as well.

> 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.

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.

It often _is_ the most sensible choice, _for them_. The problem is, not everyone is doing the same job in the same environement, and they have a hard time realizing that. Their empathy/imagination stays too close to their own experience.

... the same job in the same environment coming from the same background. If you've spent 5 years at university training yourself in vim or emacs, it makes sense to keep using that; if you've started on the job with jEdit or whatnot, it's hard to justify giving up high productivity for several years for some random promise of even-better riches down the line.

What does jEdit give you that you couldn't learn in Emacs in a day or two? Basic text editing is pretty straight forward to learn in Emacs. The part that takes time is learning all the other cool features, and that can be done gradually over time without giving up immediate productivity.

jEdit uses java-like beanshell for scripts, which is pretty different from elisp. So now you have to rewrite all your custom macros in a language you don't know and with an entirely different paradigm. But tbh, it's just an example -- any advanced workflow will require some time to adjust, for benefits which are hard to quantify.

Tried switching from QWERTY to DVORAK recently? Same thing.

>For me it's the question, why it's so hard to understand that people have different likings without to downgrade them?

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.

Who's "we"? If someone reaches a maximum of productivity using an editor made in the 70's, who is anyone else to tell them otherwise?

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.

People usually claim that one thing is more productive than the other without any real evidence. I think it's mostly just so we can stick with something out of familiarity. Or sometimes it's so we can switch to something else because we're bored. The "it feels right to me" argument just seems unbeatable (you can't argue with it without seeming like a jerk).

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.

But that's an unknown right? You may or may not be more productive in IDE Y, but making the effort to find that out takes more time, your most precious resource, for something that may not even turn out to be true, and then your investment is wasted.

I think this is why people tend to make the broad statements about "X is better than Y" since they only have their own experience to go on, but without full knowledge of how someone else's mind works, it's a fool's errand. Even if changing tools would solve the things you can observe and attach a "time wasted doing X" quantity, you don't know if they won't struggle with something else after changing.

> but making the effort to find that out takes more time

This is always true, in every domain. Sometimes it works out and sometimes it doesn't. I think it's worth some amount of effort to find out, but at some point, you have to settle on something and move on.

Personally, I used to be an emacs user, then switched to Eclipse with some emacs keybindings, then learned vim after many years of being frustrated by it, and now use an IDE with a vim plugin (and occasionally straight vim). I feel like I've settled on the best of all worlds... for _me_ at least.

> I think it's mostly just so we can stick with something out of familiarity.

That's the single best reason to stick with something as personal as an editor. Emacs, for example, has all of the features of other IDEs but with a different interface. Want to single-step through a debugger? Got it! Refactor Java? Got it! Syntax highlight 1,373 file format you've never heard of? Oh, definitely got it!

Given that for literally any feature I've seen in other IDEs and wanted to try, Emacs has already had it for a decade, I just don't have an incentive to learn a wholly different workflow.

It could be true that I could make beautiful music on a guitar, but my piano skills satisfy my music requirements. I've played a guitar long enough to enjoy it and I see the appeal, but I like playing the piano more. Both would allow me to express my intent, but I can do it more easily with the interface I've been using for several decades. Why do people keep insisting I pick up a guitar?

BTW, I had this conversation with a manager once. He wanted me to use Eclipse for Python - Python! - development and kept giving me serious grief about my "ancient" Emacs setup. We was quite serious about it, too. I finally prevailed upon him to STFU and let me work with this logic: "Are you happy with my output? You are? Great. That means Emacs works for me. I'm done talking about this."

I wish that were an exaggeration, but I really had to have this conversation with a higher-up. If I'm using Notepad but still able to get my work done on schedule and meeting our quality requirements, then back off.

>Who's "we"? If someone reaches a maximum of productivity using an editor made in the 70's, who is anyone else to tell them otherwise?

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 question was not about regulation - of course you can tell anyone to do whatever nonoptimal bullshit you want if you have power over them.

I'm asking what gives anyone the ability to make a correct judgment about tools and productivity?

>I'm asking what gives anyone the ability to make a correct judgment about tools and productivity?

Extended experience (compared to someone who've only used X, someone who has extensively used X,Y and Z editors trumps them).

Besides, some people have so narrow a view, that almost anybody even a little experienced can immediately tell (correctly) that they are not using the correct tools. E.g. people coding with Notepad...

Also, science. E.g. statistical tests with control groups et al, with teams using A or B editor, and checking for speed of writing code, number of bugs, impediments to workflows, etc.

Your extended experience is valid only for you because it represents your biases for the way your mind works. It is not valid for the larger population.

To my knowledge, no such scientific statistical tests exist with a large enough sample size.

I definitely understand what you're saying, and personally at work I use Xcode (with XVim installed).

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 :)

[0]: https://github.com/CestDiego/sweetgreen.el

> 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.

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 .

A good measure for plugins IMO is to look for ones that are very focused on a specific featureset. For example, Syntastic is plain awesome because it solves the problem of syntax/semantics checking once and for all, and does not attempt to do anything else.

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.

First of all, the key point of emacs is extensibility and customizability. So as new stuff comes up, e.g. new programming languages, debuggers, file formats, emacs can be extended without too much pain to work with them (and often, somebody has already done that for me).

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'm about to dive into org mode for the first time today. Do you have any tips for learning it?

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.)

You may find this helpful (http://sachachua.com/blog/2014/01/tips-learning-org-mode-ema...).

Also remember org mode is as simple or as complex as you want it to be!

I started reading the documentation, which is pretty good, IMHO. I use only a small fraction of org-mode's features, though. There is so much one could do with org-mode, but I don't have enough time to get acquainted with all the features and get into the habit of using them... Not right away at least.

The Org documentation is a great place to start, but this comment opened my eyes to things I was doing wrong:

https://news.ycombinator.com/item?id=11386943

Maybe learn to type right-handed so you can keep your left hand on TAB. ;)

there is a ton of stuff here

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

It's also perfectly possible to use Emacs for 20+ years and not do all that much with the extensibility (some flymake stuff is all I wrote, I think).

I use it to edit code simply because I feel at home in it, but I use very, very little of the functionality.

> the key point of emacs is extensibility and customizability

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.

You edit text. That's a big part of your "developer experience", and XCode/IntelliJ don't really change that. Most of their innovations focus on the high-level, and they tend to be serious let down when it comes to straight-forward text manipulation. No progress since CUA there.

Using a SmallTalk system was a somewhat different experience. Now that was integrated.

Smalltalk started the whole IDE idea actually.

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.

> Smalltalk started the whole IDE idea actually.

Yet as opposed to ST, Mesa or Lisp they have to integrate this with files and executables, which makes things a lot more cumbersome. And then you get something like the web, where the moving parts are even further removed from each other.

The problem is that IDEs and powerful editing aren't exactly opposites (let's not forget that Emacs is basically a Lisp IDE). But I've yet to see an IDE that comes close, mostly because the lack of a good extension language (plugins are way too heavy), and possibly because the GUI provides a bigger impedance to additions.

I really like the trend towards "headless" IDE backends.

I'm not sure this is a good idea.

I took a class that used Pharo and made my workspace freeze a couple of times.

A remote protocol talking to a 2nd vm would have been better.

I don't need to learn Qt Creator, Clion, xCode, AppCode and VS if I already know vim. Why I would to need to use a different text editor for each different language?

Unlike vim or emacs, you don't need to learn VS, Qt Creator, Clion or similar... Mostly, these tools are so intuitive, you just start being productive right after first time.

Intuitiveness depends on satisfying the user's implicit expectations. My expectation is that within a text editor, I'm able to use Vim keybindings (and my assorted plugins) to edit text.

So your assumption hinges on the expectation of a user which is not at all similar to me or most other Vim powerusers.

Hahahaha! Oh, what a beautiful world that would be.

I disagree. VS, Clion, Eclipse etc. have very different key bindings and differ significantly in the way projects are set up and regarding underlying build mechanisms. These are all things you need to learn to be proficient with a tool. Once you are beyond a superficial use of a tool, a slightly steeper initial learning curve pales in contrast of what you need to reach a certain level.

Well, then you have a GUI - menus/toolbars and after a couple of times use - you just remember the key binding usually specified along the label.

I'm not talking about superficial usage like that. I'm talking about productivity boosts like multiline edits, line swapping, cursor jumping over blocks, and more advanced tricks. Also about where to do all those little tweaks to the configuration you need to google for or ask a coworker about to get a hold of. Those are not discoverable with any GUI.

> ... Those are not discoverable with any GUI.

But kind of easy-to-guess once you have used Windows for a while. Examples (Primarily Netbeans on Windows and Linux):

Alt + shift + arrow -> move line(s) up/down or (de)indent.

Ctrl + shift + arrow up/down -> duplicate line up and down

etc.

Most of you already know I guess but I guess there are always some who didn't realize that on Windows and Linux (desktops that is) you can mostly always rely on

arrow -> move

ctrl + arrow -> move one word at a time

shift + arrow -> move while selecting

and combined:

ctrl-shift-arrow -> select whole words at a time

---

While I can find my way around vim and have also given emacs an honest try for me it was not worth it. If typing speed becomes an issue for me it is a sign of a deeper problem ;-)

That said I use a lot of multiline edits for database hacks, but what I really saves me some time and frustration when dealing with legacy code is

* Really good refactoring support

* ctrl-shift-d in Netbeans which brings up a stack of my latest cuts

* regex search/replace in Netbeans. Yes, that means you can search for something(crazyregexgoeshere)(anotherregex) and replace with somethingelse-$1-$2

If anyone is interested I might try to compile an overview of some of my workflows (no promise though)

For Emacs:

> ctrl-shift-d in Netbeans which brings up a stack of my latest cuts

Eval (or bind yourself to a key): (popup-menu 'yank-menu)

Also, the whole copy-paste infrastructure works with that "stack" ("kill ring" in Emacs speak), so you can easily paste previous cuts via pressing M-y after pasting (C-y).

> regex search/replace in Netbeans. Yes, that means you can search for something(crazyregexgoeshere)(anotherregex) and replace with somethingelse-$1-$2

M-x regexp-replace; use \N instead of $N.

Besides features related strictly to understanding of Java code semantics, it's unlikely Emacs doesn't have something Netbeans has :).

> But kind of easy-to-guess once you have used Windows for a while.

Um, no. Just line swapping is different across IDEs. The same is true for other advanced editing moves. We're not merely talking about feature set Notepad or some random edit box has.

For Emacs/Vim, the time investment to get from extendable editor to, say, a C++ IDE parity is greater than it is for a dedicated IDE. Personally, I use dedicated IDEs for where they shine (Java, C++, ...) and simple but powerful editors elsewhere. I love using Emacs for writing documentation because of all the advanced features it provides for text editing. So we're probably in the same boat on this.

My point is that once you have gone beyond the initial setup and superficial use, becoming a proficient expert at the tool takes equal effort.

> Those are not discoverable with any GUI.

Are you sure? I can _search_ in my IDE's preferences for available keybindings and all kinds of other stuff.

Depending on the meaning of "productive" of course...

If you ever develop clojure, you'll want to give emacs + cider a spin. You can develop in vim, but cider is really pretty amazing these days and there is no equivalent in vim that I'm aware of.

Each task has its own tools. You seem to have been using Emacs as surrogate for a certain IDE experience known to you. An IDE is a tool that has been carefully geared toward a certain domain and workflow. Like an office suite, it provides everything the target audience needs. It's turn-key ready and all you need, if your work never goes beyond the intended model. But IDEs are not very flexible if you deviate away from that model. On top of that they tend to be quite opaque regarding the internals (I remember VS being very annoying in that regard). Emacs, on the other hand, is basically just an editor. But it runs circles around any built-in IDE editor I have seen. On top of that, it provides extensibility. That's where the fun starts. If you're working in a domain that hasn't got any turn-key solutions yet, Emacs is a good start.

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.

To me, it's just that text editing becomes way more efficient when you can accomplish everything without reaching for the mouse.

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.

Because the experience is so much better. The power of command line is intoxicating, and going to GUI tools files like programming with hands tied behind your back and being blindfolded.

I used to think like this, but I don't any more.

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.

That's decidedly not true. Nor is this about customization of workflows. I am talking about actual unadulterated power to do things you cannot do in an IDE. All IDEs optimize for the average use case. If they do expose a set of advanced commands or transformations, they are hidden deep in the menus and what you can do with them is extremely rigid and limited. At most you have a few dozen commands (you would call them menus) available.

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.

As parent said, good IDEs (like IDEA etc) can be customized to no end. You can remap pretty much all "menu" commands to shortcuts, and they have plenty of interfaces to extend their feature-set through plugins and custom commands to invoke the shell or what-have-you.

Honestly, it's not a crime to like nice windows, y'know.

That's another misconception GUI people seem to have. You can have nice windows and color schemes in Terminal as well (even on Windows is you install MSYS2). Except you get absolute control over your windows layouts and behaviors with tmux and friends. And you don't have to reach for the mouse to interact with any of them.

Looking forward to drop shadows and brushed-metal in tmux, which you shall promptly post. Also fullscreen exposé-like dashboard with previews would be nice.

Like we don't have better things to use our processor cycles on :P. Also, I thought skeuomorphism was dead now?

It doesn't necessarily have to be skeuomorphic, but I like to burn some processor cycles making different things look different, not necessarily brushed-metal attractive. So my todo-list files don't look like my source code files which don't look my terminal windows, which helps me tell what's what.

(And it's beside the point, but brushed metal has been dead for years by now!)

Funny enough, iTerm2 has expose for its tabs, but I never use it. It's just not how I work. Drop shadows are not needed, since in iTerm2 or tmux the entire active windows is brighter and all others become slightly greyed out, so you never confuse what has focus.

Bushed metal on the other hand is not something I want or desire.

> It's just not how I work.

... which means nobody else needs it, right? :)

I never implied that everyone should use the command line or that GUIs are evil or bad. I was just answering the query "why people still use command lines" to the original post.

> "That's decidedly not true. Nor is this about customization of workflows. I am talking about actual unadulterated power to do things you cannot do in an IDE. All IDEs optimize for the average use case. If they do expose a set of advanced commands or transformations, they are hidden deep in the menus and what you can do with them is extremely rigid and limited. At most you have a few dozen commands (you would call them menus) available."

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/...

You are assuming I never use any GUI tools or never try IDEs. I do. I know how customizable most of them are (all except XCode which is absolute garbage). And you can spend a lot of time doing that (writing your own extensions or invoking those external command line tools on your text selections etc), but why bother spending time on that when I can use those tools directly in the command line? And if I'm going to write an extension (that's already programming something) then I might as well do it in the command line, and use it anywhere I can edit text.

Can you give me one example of a command line tool you wrote to help you get your work done?

Just today I wrote a custom git command to help me sync my branch with master without having to first git checkout master, git pull, git checkout <my_branch>, git rebase master and deal with conflicts.

I chose BASH for my language of choice, but could have use Python or Ruby or anything that the shell can execute.

In Visual Studio, creating a custom keybinding appears to involve three dropdown menus, a dialog box, and at least two UI controls.

In Emacs or Vim, it's a single line of code you add to your initialization file.

I think there may be different definitions of "easy" in play here. I'll concede that Visual Studio makes custom keybindings possible, but so does any text editor worthy of even momentary consideration as a professional tool.

And I'll take your challenge. Here's something I can do in Emacs: I can take a spreadsheet received from a client, full of intended configuration settings for a custom internal application. I can export it as CSV, load it in Emacs as such, and extract the relevant sections of the content into tables in a plaintext Org-mode document. I can then add a function to that document, in whatever language I choose, which will receive the contents of those tables as structured data in the language's own idiom, and generate the collection of complex SQL statements necessary to implement the desired configuration. From there I can decide whether I want this SQL script inserted into the document I'm writing, or written out to a file that I can copy to a remote host and feed to the SQL monitor. Or I can instead have Emacs itself connect to the target RDBMS and apply the configuration directly. Or any combination of those. And once the document's written, I can do all this with a single keystroke. Another single keystroke exports the document to HTML, so I can share it with the client to demonstrate exactly how their intent has been translated to reality, and with colleagues so they can see what's been done.

Perhaps that sounds fantastic to some. For me, it's Thursday before last. It took a little less than an hour.

I'm sure Visual Studio suits your needs quite well. I'm glad of that; everyone should have a tool that does what they need it to. But Visual Studio, from all I've seen of it, does very little to expand the scope of what you can do. Those of us who are fond of Emacs or Vim are so because, by comparison with something like Visual Studio, Emacs and Vim give you superpowers.

> "And I'll take your challenge. Here's something I can do in Emacs: I can take a spreadsheet received from a client, full of intended configuration settings for a custom internal application. I can export it as CSV, load it in Emacs as such, and extract the relevant sections of the content into tables in a plaintext Org-mode document. I can then add a function to that document, in whatever language I choose, which will receive the contents of those tables as structured data in the language's own idiom, and generate the collection of complex SQL statements necessary to implement the desired configuration. From there I can decide whether I want this SQL script inserted into the document I'm writing, or written out to a file that I can copy to a remote host and feed to the SQL monitor. Or I can instead have Emacs itself connect to the target RDBMS and apply the configuration directly. Or any combination of those. And once the document's written, I can do all this with a single keystroke. Another single keystroke exports the document to HTML, so I can share it with the client to demonstrate exactly how their intent has been translated to reality, and with colleagues so they can see what's been done."

Okay, so let's look at this. If I've understood correctly, you want to be able to generate data migration code based on a CSV file, and export that code so that it's ready to be inserted into documentation, is that a fair assessment?

So for Visual Studio, one way to do this would be to write a custom runner for Fluent Migrator:

https://github.com/schambers/fluentmigrator

https://www.nuget.org/packages/FluentMigrator/

https://www.nuget.org/packages/FluentMigrator.Tools/

Nope. This isn't a migration; it's one-off data population. Fluent Migrator can do that, from its documentation, but it wouldn't be required, and since this isn't a migration, Fluent Migrator doesn't really bring anything to the table that I can see. So you're building a custom software project in your language of choice, with all the overhead that implies. In the workflow I described, you create a file and activate Org-mode. (Or just create a file whose name ends with ".org".)

There's also the documentation task, which has to include the source data and resulting SQL script, as well as the transformation code. I'm not seeing anything here that would simplify that in the slightest; you'd have to either write the HTML document by hand, or write code to generate HTML. In the workflow I described, all that code is already written, and you can invoke it with a single keystroke.

And beyond that, there's the matter of data ingestion. You're starting from CSVs, so you have to read those and parse them just to have the data you need to work with in a form which you can use. Any serious language has a CSV parsing library, of course, so that's not a difficult task in its own right, but it's still more code you have to write, and more effort you have to put in - selecting a CSV parser, adding it to the project, learning its API, et cetera. In the workflow I described, it's a copy-paste operation.

Don't get me wrong - I didn't say, or assume, that anything I described couldn't be done in Visual Studio. But at this point we're talking about, what, a few hours at least? And you're spending a fair chunk of that time on overhead, especially in document generation. You have to find, vet, and install libraries, write or modify a bunch of code, and so forth. By the time you're done, you've probably had to spend the better part of a day on this one task.

In the workflow I described, the only code I needed to write was that in which I expressed the actual transformation from tabular data to SQL statements. Everything else, Emacs and Org-mode took care of for me; all I needed to know was how to invoke capabilities already present. And I had the job done and dusted in less than an hour, with plenty of time left in my day for other work.

That's what I mean when I say Emacs and Vim give you superpowers - not that there's anything you can do in one of those editors that (with enough effort) you can't do in another environment, but that those editors are better than anything else (at least anything else I or anyone I know has ever encountered) at helping you get more done, faster, without having to spend time on ancillaries that distract you from the meat of the task at hand.

> "In the workflow I described, all that code is already written, and you can invoke it with a single keystroke."

The thing is, if that's the case, what you're describing isn't a custom plugin, it's an existing plugin someone else has taken time to write that you're making use of. If that's the argument you're making then you could say Emacs has a better ecosystem of plugins, and that it's easier to tie them together, is that what you're trying to state?

It's a subset, and the Blub paradox applies.

For one thing, Org isn't a plugin; it's part of the Emacs distribution, rather than something you have to explicitly install. All you need to do to use all the functionality I described is install Emacs and start it up.

For another, Emacs doesn't actually have a plugin system, per se. Instead of the usual headache, where a program written in language A exposes a lossy subset of itself to plugins written in language B, Emacs just exposes all of the language in which it itself is written, and you can do what you like. The usual distinction between first-class application code and second-class plugin code doesn't exist. There's just Emacs Lisp code, any of which can freely interact with any other Emacs Lisp code running in the same process space, including effectively all of Emacs itself.

You can add new code by installing packages from a repository, which you can do in a single command if you know the name of the plugin you want. (If you don't, there's a searchable list.) Or you can do it by opening an Emacs Lisp buffer, writing some code, and evaluating it - again, with a single keystroke. If you like it and want to keep it around, save it to a file: boom, it's a "plugin". Add a line to your init file to load it, and it's a "plugin" you're using. Or you can just drop your new code into your init file directly, because your init file is - you guessed it - just Emacs Lisp code, that happens to be in a file Emacs will load and execute when it starts up.

As I said before, the Blub paradox applies: it's easy to recognize something less powerful than what you're familiar with as such, but something more powerful just looks weird. From the sound of it, Emacs looks very weird to you. It did to me, too, before I started using it. Now I won't willingly use anything else. Perhaps I'm just very weird, too.

> "As I said before, the Blub paradox applies: it's easy to recognize something less powerful than what you're familiar with as such, but something more powerful just looks weird. From the sound of it, Emacs looks very weird to you. It did to me, too, before I started using it. Now I won't willingly use anything else. Perhaps I'm just very weird, too."

Nah, it's nothing to do with the blub paradox. I've dabbled with Emacs before, I could see certain benefits to its flexibility, but was put off by other factors such as the clunky keyboard shortcuts (which is why I'm glad for both ergoemacs and spacemacs, as they have better defaults IMO), reliance on Lisp and a couple of other minor issues. Overall I think it's a great tool, and I can see why its popular.

That said, using the blub paradox implies (whether you intended to or not) that you believe it's more powerful than the competition. The way I see it is that any program is only as good as its existing features. Org mode is a good example of a strong feature for Emacs, but I could point out a number of strong feature for VS too. IntelliTest is a good example:

https://msdn.microsoft.com/en-us/library/dn823749.aspx

IntelliTrace is another:

https://visualstudiomagazine.com/articles/2012/02/07/intelli...

If someone has only ever debugged using print statements or breakpoints then they miss the power of such features, so I could just as easily invoke the blub paradox with reference to VS as well.

The point is there is not one single ultimate tool, they all have strengths and weaknesses. Emacs is not a paradigm shift better than VS, and VS is not a paradigm shift better than Emacs, so the blub paradox does not apply.

Visual Studio integrates well with the capabilities of C++ and of languages that run on the CLR. Outside that realm, it can do little or nothing for you.

Emacs integrates well with the same capabilities in almost any language that provides them - even C#.

See the difference?

And you're hardly alone in doing Magic Things in org-mode. Org-mode is like the storied elephant being groped by blind men, all finding a different piece of anatomy, and each concluding that the elephant is something different.

Org-mode is a best-of-breed outlining application. It's a dead-simple workflow management and time tracking application. Org-mode is a better Markdown than Markdown integrated with a multi-format publication generation capability. Org-mode is a literate programming environment facilitating reproducible research that allows embedding code inside documentation, but unlike some alternatives supports a zillion languages and lets you pass values between them.

I haven't found anything that I like as well as org-mode for any of those individual tasks, much ALL of them. Org-mode somehow does all these things and manages simplicity. It's all plain text that I never have to fret compatibility or corruption.

> Org-mode is a better Markdown than Markdown integrated with a multi-format publication generation capability.

It can even export to Markdown! (And I'll only author in Markdown under duress anymore.)

It's funny that you chose the phrase "Magic Things". Before I settled on the "superpower" metaphor, I was going to talk about the times when I've done things with Emacs, in and out of Org-mode, that have made my colleagues say things like "wow, that's really cool" or "holy shit how did you even just do that". I opted not to because I figured it would sound like bragging, on the one hand, and on the other because you can do things in Emacs that really do have to be seen to be believed. But "magic" is the word I was going to use.

(It's not always an advantage, either. I've had people show contempt for things like Org-mode tables, on the assumption that because they're rendered in text, they can't possibly be anything other than text, and I must be wasting insane amounts of time making columns line up and the like. I used to work for one of those people. I'm really glad I don't work for him any more.)

The thing is, I'm a programmer. I want to extend my tools with code, not configuration. The power of the command line is not so much that it's a command line -- the power is that it is a programmable environment. I'm not limited to configuring what the tools are doing on my behalf. I'm writing my own tools.

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.

> "I want to extend my tools with code, not configuration."

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...

Yes, but writing a Visual Studio extension (or Eclipse, etc.) is much higher friction than Emacs. In emacs, I can just open a buffer in emacs-lisp-mode, write a quick function, immediately eval it and start using it. The instant feedback means that quick, small customizations are very low cost. It's like the difference between writing a code generator for Java vs using macros in Lisp.

I see. Can you give me an example of a function you wrote in that way?

Not OP, but a very quick and simple example of something I put in my .emacs very long time ago:

  (defconst trc-comment-keywords "\\<\\(FIXME\\|TODO\\|BUG\\|HACK\\|NOTE\\|WARNING\\|ERROR\\)")

  ;; Install the word coloring
  (defun add-comment-keywords ()
    (font-lock-add-keywords nil
                            `((,trc-comment-keywords 1 font-lock-warning-face t))))

  (add-hook 'find-file-hooks 'add-comment-keywords t)
  (set-face-underline 'font-lock-warning-face "yellow") ; Just make sure we'll see it

This defines a function #'add-comment-keywords and adds it as a hook to the "open file" operation. The function highlights all matches to the regexp in trc-comment-keywords so that they're highlighted in the source code using a modified font-lock-warning-face.

This is an example of something you could just type in and evaluate right there, in your buffer. Later, you can save it in your init file to have it always enabled.

A more complicated example of related code I wrote with some help from the Internet and the Emacs documentation:

  (defun list-comment-notes ()
    "List all TODO/FIXME/HACK, itp. in a new buffer for reference."
      (interactive)
    (save-excursion
      (goto-char (point-min))
      (let ((collected-lines '()))
        (while (re-search-forward trc-comment-keywords nil t)
          ;; collect lines
          (setq collected-lines (cons 
                                 (format "%d: %s" (line-number-at-pos) (grab-current-line))
                                 collected-lines)))
  
        ;; generate a new buffer
        (let ((notes-buffer (generate-new-buffer (concat (buffer-name) "-comment-notes"))))
          (set-buffer notes-buffer)
          ;; dump collected stuff to here.
          (dolist (a-line collected-lines)
            (insert a-line)
            (insert "\n"))))))

What it does is it scans the current buffer for all occurrences of the keywords and lists them in a new buffer (with "-comment-notes" appended to the name). It's a crude function that could use some improvements, but it works well enough and is now just a M-x list-comment-notes away. Or, with the way M-x works, just M-x l-c-n away. Or I could bind it to a key.

The great thing about Emacs is that all you need to extend it is to type the source somewhere. No need for creating projects, build scripts, rebooting your editor, etc. You can evalute and reevaluate the code until it does what you want. Lisp interactivity, which Emacs inherits, is addicting and still unparalleled in other programming languages / environments.

Here are three of mine:

    (defun tom/insert-sterling-symbol ()
      (interactive)
      (insert "£"))

    (defun tom/set-buffer-modified ()
      (interactive)
      (set-buffer-modified-p 't))

    (defun tom/unix ()
      "Set buffer to unix line endings"
      (interactive)
      (set-buffer-file-coding-system 'unix))

The last one exists only because I could never remember the right command to select Unix-style line endings. So rather than train myself to learn it, I just wrote a small wrapper with an obvious (to me...) name, because it's so easy to do that.

I've written some Visual Studio addins as well... the experience is not really comparable. (Visual Studio VBA macros, when it supported that, were painful too.) emacs makes it a lot easier.

Incidentally, C-x 8 is by default bound to a keymap that includes a lot of glyphs not often found on keyboards. You can insert £ with C-x 8 L, which might be more convenient than M-x tom/insert-sterling-symbol RET.

Not OP, but I recently installed the Emacs flavor of the widely used Emmet HTML generation tool, and I found myself wanting to customize some aspects of its behavior so that they better suited our in-house style.

I could've edited the Emmet source code in place, but to do so would've meant losing my customizations next time I upgraded the package. I could have forked it, but that would mean having to manually merge changes into the fork every time a new release comes out.

Instead, after a couple hours of reading the Emmet source and fiddling around in an Emacs Lisp buffer, I ended up with this:

    (defcustom emmet-verticalize-html-attributes nil
      "Whether to verticalize attributes in HTML tags.
    
    \"Verticalize\" here means to separate each pair of attributes by
    newline and enough indentation to line up the first character of
    attribute names. For example, the unverticalized production
    
    <div id=\"foo\" class=\"bar\"></div>
    
    when verticalized becomes
    
    <div id=\"foo\"
         class=\"bar\"></div>"
      :type 'boolean
      :group 'emmet)
    
    (defcustom emmet-verticalize-minimum-attributes 3
      "The minimum number of attributes required for
    verticalization. If a tag has fewer than this many
    attributes. they will not be verticalized, even when
    verticalization is enabled.
    
    Values less than 2 have no effect, since verticalization only has
    an effect on tags with at least two attributes."
      :type 'integer
      :group 'emmet)
    
    (defun emmet-verticalize-html-tag (orig &rest args)
      (let ((html (apply orig args))
            (attribute-count 0))
        (if (null emmet-verticalize-html-attributes)
            html
            (save-match-data
              (with-temp-buffer
                (insert html)
                (html-mode)
                (goto-char (point-min))
                (while (re-search-forward (pcre-to-elisp "^\\<[^\\/]\\S+") nil t)
                  (while (and (not (= (point) (point-max)))
                              (not (looking-at (pcre-to-elisp "\\/?>")))
                              (re-search-forward (pcre-to-elisp "\\w[\\w\\d_-]+\\=\\\".*?\\\"" ) nil t))
                    (setq attribute-count (1+ attribute-count))
                    (and (not (looking-at (pcre-to-elisp "\\/?>")))
                         (newline-and-indent))))
                (indent-region (point-min) (point-max))
                (if (>= attribute-count emmet-verticalize-minimum-attributes)
                    (buffer-substring-no-properties (point-min) (point-max))
                    html))))))
    
    (advice-add 'emmet-make-html-tag :around #'emmet-verticalize-html-tag)
    
    (defcustom emmet-indent-html t
      "Whether or not to indent generated HTML according to the same rules
    used by `html-mode'.
    
    When non-nil, Emmet-generated HTML will be indented via
    `html-mode', with a newline after every closing angle bracket.
    
    When nil, Emmet-generated HTML won't be post-processed in this
    way. (The version of Emmet I'm using, 1.0.8, applies no
    indentation whatsoever.)"
      :type 'boolean
      :group 'emmet)
    
    (defun emmet-indent-html-snippet (html)
      (if (not emmet-indent-html)
          html
          (save-match-data
            (with-temp-buffer
              (insert html)
              (goto-char (point-min))
              (while (and (re-search-forward (pcre-to-elisp "\\>") nil t)
                          (not (eobp)))
                (newline))
              (goto-char (point-min))
              (while (search-forward "\n\n" nil t)
                (replace-match "\n" nil t))
              (html-mode)
              (indent-region (point-min) (point-max))
              (buffer-substring-no-properties (point-min) (point-max))))))
    
    (advice-add 'emmet-make-html-tag :filter-return #'emmet-indent-html-snippet)

...which not only implements the behavior I desire, and does so without modifying the original source or breaking my ability to upgrade Emmet, but also adds customization options to those provided by stock Emmet, so that I can adjust the way my Emmet extensions behave without having to touch the code. (Not that touching the code is any great hardship, but it's nice to be able to adjust the way these extensions behave in the same interface I use to make other minor adjustments to the way Emmet works.)

Shortly after I copied that code into the Emacs buffer I'm using (via Firefox's "It's All Text!" extension) to edit this comment, but before posting, I inadvertently killed Emacs's message buffer, which contains a running log of everything displayed in the editor's echo area. I wasn't prompted for confirmation before killing that buffer, but I felt I should've been. So I opened an Emacs Lisp buffer and wrote this:

    (defun defend-message-buffer (kill-fun &rest args)
      (let* ((buf (car args))
             (buf-name (if (stringp buf)
                           buf
                           (substring-no-properties (buffer-name buf)))))
        (if (string= buf-name "*Messages*")
            (and (yes-or-no-p "Really kill the message buffer? ")
                 (funcall kill-fun buf))
            (funcall kill-fun buf))))
    
    (advice-add 'kill-buffer :around #'defend-message-buffer)

And now I am.

Visual Studio had a pretty nice macro record and playback system that was great for ephemeral, low friction scripts. They removed it because they said nobody used it.

I switched to AutoHotKey and now I have a macro system that works everywhere.

"just like in Emacs."

There are many thing you can do, but it really, really isn't just like emacs.

> "There are many thing you can do, but it really, really isn't just like emacs."

"a built-in package manager, just like in Emacs."

They both have built-in package managers for extensions. I don't think this is a controversial statement.

That is fair - I mis-read "just like emacs" in your original. Apologies.

The extension mechanism really isn't like emacs at all. Package management is a bit more similar (although can you easily add new repositories for nuget?)

> "although can you easily add new repositories for nuget?"

Yes. Here's a guide showing how to create a local Nuget repository:

http://codurance.com/2015/05/04/creating-a-local-nuget-repos...

In the guide you can see this screenshot:

http://codurance.com/assets/img/custom/blog/2015-05-01-creat...

Which shows you one way to set up the package source.

Also worth mentioning Paket, which is a Nuget replacement. In addition to working with the standard Nuget library, Paket can pull dependencies directly from Git repos.

https://fsprojects.github.io/Paket/

cool, thanks.

I apologise in advance if this sounds dismissive, but: I've tried to use both Vim and Emacs and Neovim and Spacemacs, and every time my pain point is that they're designed for use on the command line rather than as an environment I can switch in and out of. I know this isn't strictly true as both editors can be run as separate applications that you don't quit for weeks, but their roots have persisted into how they're expected to be used.

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.

Short life times for vim are more a thing on remote sessions, e.g. for server configuration. I agree with you, that such a work flow is suboptimal for the general development case, so I will just describe what works for me:

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).

Yeah, I do still use vim on remote sessions where I know I'm just going to be making a small change and then be done with it -- losing your entire environment or history is a lot less worrying in that case, and it's way easier than mounting the server locally or something.

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.

It seems like your major objection is persistence of your session (which is more than just editor instances) but it includes your shells, their position on filesystem, your terminal splits, their position and color etc. There is a tool that handles exactly that and its called tmux. It allows you to create a session (or multiple sessions), create windows, position them exactly the way you like, open your editor of choice in one or more of them, or have other tools display useful information etc. And these session survive restarts, and you can connect to them through ssh etc. And you can navigate those windows with keyboard or mouse etc.

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.

Like a lot of things in technology, everything forms an island where you start to really appreciate the things you have and ignore the things you don't. If you use any other editor, I'm sure you'd miss being able to zip around editing files the same way I miss session persistence!

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.

This is strange to me, coming from the Unix philosophy of ‘do one thing well’. I don't expect a text editor to manage windows; I use a window manager for that. Then my (highly personalized) window management works the same for everything, not just text editing.

I find it strange that you find it strange, because I agree: leave the window-managing to the window managers, and the text-editing to the text editors! I posted a very similar reply to a comment about the Min browser; too many applications try to re-invent basic concepts such as windows or tabs. All a text editor should do is give you windows to work with, then leave it up to you to position them.

The problems you've described make sense. They're not problems I have because I generally don't exit Emacs (and I don't use it on the command line, but in server mode with GUI clients), but if I did, I'd want to come back to the same environment I left. Changes you know you want to keep, you can add to your initialization code so that they're reapplied on the next startup, but that's not the same, and it doesn't cover ephemera at all.

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 agree with you that session persistence is generally lacking in a most of these tools.

I there an editor/IDE you use that gives you the persistence?

Smalltalk and commercial Common Lisp environments come to mind, where you can save the working session as an image.

Most modern IDEs also have a notion of session.

Emacs is free software developed by a worldwide community. It's a culture, an ecosystem, a way of life. The same with Vim, but I'm into Emacs. I love Lisp deeply, and I think Emacs is a truly amazing piece of technology.

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 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.

Sure, but my point is that Xcode is aimed at the development of programs for Apple's proprietary systems, while Emacs is made for the purpose of empowering free software developers, and that all of this is one reason why I personally love Emacs and strongly prefer it over proprietary IDEs.

> Weird things would go wrong and I had no idea how to fix them.

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".

Same here. I have emacs init.el file that I'd like to tinker with from time to time but every time I try to make switch I feel like I'm using a system consisting of thousands of moving parts which constantly break.

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.

Write one, then. I did. It's not hard. Mine's about 7K lines of code and it's the perfect text editor for me.

Do you have fun integrating every new mode that you might like to use when you decide to open a source file for a new programming language?

I think that what you're trying to express is that I might be wasting some time implementing support for some syntax highlighting and code formatting features that are already present in other editors. Thank you for your concern. It hasn't been much of a problem since (1) I don't really used much syntax highlighting other than for reserved words, string literals and comments, and paired bracketing characters, (2) I rarely need to view or edit files besides C/C++/Haskell/bash/LaTeX, which I have support for, and (3) the editor works just fine on other files without fancy-pants modes anyway.

It's funny this idea that you can't edit source code without a special "mode". It's just plain text, come on!

Sure, stuff can go wrong with Emacs! I don't know anything about Spacemacs... but what I mean is that Emacs invites people to learn about the system, study its source code, change it, and fix stuff—whereas Xcode is completely proprietary, so that when things don't work there is literally no way to do anything about it except ask Apple to please fix it.

> 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.

Because i develop on very expensive hardware on a different continent. I also end up with a decent mental model of my code.

You have a strange way of writing CLion and Xcode. Your way makes it harder to see what you are talking about.

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 even less efficient and ergonomic than mice which are pretty terrible at both those things. Track balls and pads are only a tiny improvement. All of these input methods are deeply flawed but there are no real alternatives that I know of. There's plenty of us that would move to better, more efficient, more ergonomic input methods were they available.

I use a magic trackpad and find it very good at giving me the best features of a mouse/pointer interface and a touch interface combined. You can do things like two-finger scroll in any document and 3 finger swipe between desktops minority report style... All kidding aside, it seems very productive, but I still keep a mouse plugged in just in case I need to run Visio inside a Windows 10 VM to do some diagraming... Mouse is much more precise and less fatiguing to use for serious diagramming...

>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.

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.

Mice are not a 100% replacement for keyboards. If you're doing lots of typing, there is something to be said for keeping your hands on the keyboard. Vim and emacs facilitate this much better than GUI-based editors.

>Mice are not a 100% replacement for keyboards.

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.

>On the other hand, mice-based GUIs ARE a 100% replacement for CLIs.

Really? I can automate a pipeline of GUIs? Please show me how I can automatically query a database, take that output, run complex data aggregation over those results combined with past results, send that to a remote server for storage, and email myself the result of the upload, using only a combination of GUIs.

(Points deducted for anything that involves instructing the machine to "move mouse to position (x,y)", since screen sizes may vary and where an individual GUI chooses to pop open a dialog/modal may also vary)

AppleScript can do pretty complex GUI automation tasks.

Yeah, so can AutoIT or python with pywinauto... you could do it. It just wouldn't be pleasant. Might do it if you had to extract data from some proprietary GUI tool you couldn't tear open.

Windows 3.1 had a macro recorder that allow to automate task over a GUI.

I think he was saying that a mouse-based GUI can display a terminal window in which one can run a CLI; thus a GUI is a strict superset of a CLI.

That's true enough, although honestly I'm at a point in my computing where the G part of the GUI is pretty limited: my windows are all full-screen; the only clicking I regularly do is on links and tabs, and sometimes text (honestly, I'm trying to use the keyboard more for that though); almost all of my command execution is keyboard-driven (there's a reason man developed language rather than pointing and grunting).

> I think he was saying that a mouse-based GUI can display a terminal window in which one can run a CLI; thus a GUI is a strict superset of a CLI.

That's not strictly fair because running ncurses applications inside split tmux panes would give you a GUI-like UI inside a command line environment. Also some of the more esoteric WM's would provide that kind of functionality as well.

The main reason it's more common to run CLI inside a GUI is really just a matter of convenience.

You also get access to the whole world of GUI applications.

Watching video and editing pictures is not much fun with only ncurses... (ascii video hardly took the world by storm).

There's no reason you can't have a CLI interface with graphics support. Granted the vt100-style terminals can't easily do it, but it was possible with the old REPL machines of the 80s (eg most micro computers which booted into a BASIC interpreter).

There are some also some terminal emulators in Linux that support inlined graphics, however I'm not sure how easy it would be to run them as a WM.

Hence why we GUI guys rather use a REPL than a plain UNIX CLI.

Graphics, the expressiveness of a sane programming language and interaction with the complete OS stack.

Firstly, Bash et al is a REPL in it's own right. What you're discussing there is that UNIX shells make a rubbish programming environment, which is a completely different argument to anything that was being discussed here. For example, DOS can inline graphics as well (proper DOS, not Windows' cmd.exe). So to follow the linked tangent you've made: DOSbox is also a better REPL than UNIX shells. Obviously neither of us would agree with that - even with our criticism of Bash et al. So equally your implied correlation is false.

Secondly, your point about "interaction with the complete OS stack", suggesting that CLI interfaces don't have access to the complete OS stack, is completely wrong. If that were the case then Linux and UNIX servers wouldn't typically run headless. A GUI is a shell. The CLI is a shell. Some platforms place more love to graphical shells than command line shells (eg Windows). Other platforms empower command line shells (eg UNIX). To argue that one is better than another is about as futile as saying the colour purple is better than the colour orange. In short, it's personal preference; not irrefutable fact.

UNIX shells aren't a REPL because 99% of their features are implemented in external commands. The shell is reduced to orchestrate logic between those commands.

None of the common ones, ash, sh, bash.... provide a rich programming environment that doesn't rely on external commands.

Interaction with the whole OS goes back to Lisp Machines, Interlisp-D, Mesa/Cedar, Smalltalk, Oberon REPL experiences. Nothing to do with running headless, which means you didn't got the message.

In those environments I can via the REPL directly interact with running applications from the REPL. For example, search for a specific text in all open windows and act upon it if found.

The whole OS API is exposed in the REPL via library calls.

No UNIX shell provides this expressiveness without relying on external commands and applications implementing specific APIs like dbus.

>Really? I can automate a pipeline of GUIs? Please show me how I can automatically query a database, take that output, run complex data aggregation over those results combined with past results, send that to a remote server for storage, and email myself the result of the upload, using only a combination of GUIs.

Yes, you can, and we have been doing it for decades, e.g. Automator on OS X.

Especially stuff like this is quite easily achievable: "query a database, take that output, run complex data aggregation over those results combined with past results, send that to a remote server for storage, and email myself the result of the upload, using only a combination of GUIs".

Not only that, but pipeline steps can trivially include "run a specific cli program with this as an input and pass the output to another program" (where the previous/after program can be GUI or CLI or a remote service, etc).

Nothing precludes a program with a GUI from taking formal parameters (in whatever format) and being scriptable and pipelined to other such programs.

Whether your question is if this is true for a particular program P, it might, or it might not. That's no different from command line programs which might or might not be pipeline-able between them without intermediaries doing custom scraping, parsing and massaging.

Other scriptable solutions for GUI programs but without GUI-based visual mixing and matching of pipelines include Applescript (and it's Javascript incarnation), Microsoft PowerShell, etc. This are textual based, but not CLI -- you can run them from an IDE for all the extra power that gives.

Also macro recording/playing (available in lots of GUI apps) means you don't have to write anything like "click window at pixel x,y".

And of course in the trivial case, a mice GUI can run any terminal emulator too -- making it a superset of CLI, since the GUI terminal can also include buttons, menus, show images, etc -- which a command line interface cannot -- so it gets the best of both worlds.

While more complicated, CLIs tend to be more expressive, easier to program as a platform and simpler to communicate between than GUIs.

Expressive, because they are built on top of (and as a part of) languages. You can do this in a GUI, but it seems to be rare; instead the program typically defines how you manage inputs and outputs.

They are easy to program for. GUIs typically require an additional framework (and are still difficult to build).

CLI typically communicates over plain text. Getting two GUI programs to talk to each other is typically very difficult. You can string a bundle of CLI commands together and build new functionality, but this is much more difficult with a GUI. This is partly a philosophical difference; the CLI platform encourages plaintext interop, but a GUI platform typically encourages isolated programs (possibly with API).

That said, nothing is perfect. There are plenty of instances were a GUI is better. People can understand visual data better and notably it's far easier to understand in an intuitive way. But it's certainly not a 100% replacement.

If you're willing to say a mouse GUI is 100% replacement for CLI, then I don't see why you can't argue that a clicking on a virtual keyboard makes physical keyboards obsolete.

Because CLI and keyboard access are two different things.

The fact that one can do all CLI work on a GUI doesn't mean that typing on a virtual keyboard is as convenient as typing on a physical one for typing tasks.

Are people under the impression that mice GUIs mean that one doesn't use the keyboard? Mice GUIs have both shortcuts AND text entry boxes a-plenty. They even have terminals.

It's the CLI that doesn't have access to all these stuff.

As if touchscreens were a replacement for mice. Mice input is more precise than touchscreens and suited for different tasks.

> 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.

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).

I value very different things than you do. Vim and Emacs have a more difficult learning curve but the beauty of it... and configuring it to your liking is that it can surpass in speed and capabilities what some very convenient editors can do for a single language.

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.

> I use MacVim and my .vimrc file follows me around wherever I go.

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.

> Atom is a great example of an editor that is aware of the internet existing. Vim, while my daily driver, is not.

I don't know how I'd securely and easily have a powerful editor configuration follow me around.

A powerful editor can do damaging things: it interacts with its host system; it can run commands; it can read and edit any files on disk; it can access the network. That means that I — not some web site run by attention-deficit VCs and subject to any number of hostile governments — must have ultimate control over what it can do.

So it has to be secure. But security means that the configuration may not be visible to others (because it may contain information I choose not to release) and it means that the configuration I fetch today must verifiably be the configuration I pushed yesterday. That means hashes, and signing, and identities.

None of that is easy, and building that infrastructure just for trading editor-configs seems like a waste. Wouldn't it be nice to have a general infrastructure for that?

So maybe it makes sense to sync editor configs around after all.

>Atom is a great example of an editor that is aware of the internet existing. Vim, while my daily driver, is not.

In what way?

Auto-update of plugins. Plugin listing, download, and installation.

One of my primary reasons for using emacs is because I decided I wanted to learn how to do as much of my computing from a terminal as possible, and emacs is closer to an OS itself than just a txt editor. (I know enough vi vim to do just fine when on systems without emacs though.)

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.

At my last job, I was doing mostly Java server stuff.

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.

Have you tried Vrapper, or any other Eclipse Vim plugin like viPlugin or Eclim?

Or if you use IntelliJ Idea it also has a plugin for Vim

The Vim emulation plugin that ships with Intellij IDEA is absolutely awful. I used it for about 30 minutes, then uninstalled it in frustration. Certain commands just didn't work right, and some didn't work at all. There was also no indication whatsoever of what mode you were in, so you just had to keep track of it in your head. The experience was not pleasant at all. I'd rather have no Vim emulation than poor emulation (same reason I ditched spacemacs after an hour or so).

I'm wondering what you thought the worse omissions on it were. I've used IdeaVim on Android Studio, and find it passable, if not great. My main beefs that I can think of right now are that my vimrc commands for leader+j and k mapping to 10j and k don't work, and it sometimes messes up the spacing on blank lines, causing the { and } jumps to not work right. I'm pretty sure the cursor changing on mode switch worked right for me.

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.

I honestly can't remember the details now, because it was quite some time ago. I just remember getting fed up rather quickly and returning to the default keybindings. Perhaps the situation has improved since then.

IIRC I tried Eclim a long time ago but couldn't get it to run reliably or at all (fuzzy memory).

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).

use the VI plugin for eclipse. At least can handle :w and :%s

You seem to be under the impression that Emacs and Vim haven't been improving over all those years.

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.

Vi emulation for those editors keeps me sane when using them

I have used VS since I started working. I recently have dived head first into NVIM for my personal stuff. I love the fact that it doesn't have all the bloated crap that the full blown IDE's have. Sure some things like going to definitions are nice, but I rarely miss them. I love just the minimalism of a great text editor and there isn't a better one in my personal opinion than VIM or any of it's variants.

> 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.

Because for a lot of tasks using the mouse is garbage compared to the speed you can get using the keyboard.

It's not like you can't use keyboard shortcuts in a modern IDE. And for some tasks using the mouse actually is faster. I think there's some research by Apple (?) that shows this.

I definitely don't think it's black or white. If you could have the power of vim (all vim, not just the basics) within an IDE, I'm sure a lot of people would be significantly more productive than only using vim or emacs. I think part of what neovim attemps to do is bringing all vim inside IDEs. That said, I have a feeling that people believe that all vim users use the editor with no plugins or config whatsoever. There are a lot of plugins out there that, while not bringing all an IDE has to offer, provide a lot of what someone would expect from an IDE, and if that is enough, I don't see why someone couldn't be more productive in it than in an IDE.

  > I think there's some research by Apple (?) that shows this.

There was, but it was bogus. The subjects were given a paragraph in which every ‘e’ had been replaced by a bar ‘|’ and they had to change them back. But they were only allowed to use the basic Macintosh text box, so they had to use the cursor keys to move to each ‘|’, delete it, and type an ‘e’. Obviously (obvious to vi users, anyway) this is not an efficient way to use the keyboard. :s/|/e/g

Yeah, I was wondering if maybe that research didn't apply to power users. Regardless, for me personally, I mostly use the keyboard in an IDE (vim style) but find the mouse is much better for certain things. Even when I use straight vim, I often find that it's easier to visually target something with the mouse versus using search or motion commands.

A good bit of my job consists of hopping onto a customer's server via SSH. Vim is about the only thing I can be reasonably confident will be installed on a standard Redhat/Centos server that I can use for looking at logs, manipulating scripts, etc.

I say this as an IDE guy (I use Qt Creator, VS and Eclipse at work all day and PyCharm for my quick hacks). I've been picking up some emacs here and there, there are a few huge advantages to something like emacs over a typical IDE:

- 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.

I too came from the Borland IDEs (I used to work at Borland).

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.

People have already given a lot of answers, but there's one thing that annoys me specifically about Visual Studio and Xcode.

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.

The fact that I can customize VIM to suit my needs with modern methods and plugins that bring same kind of functionality found in more modern editors/development envs to the powerhouse that is VIM.

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.

One of the things that keeps me in VS (with VsVim) versus actual Vim for C# is that, for strictly typed languages, the autocomplete can't be beat. AFAIK, Vim autocomplete solutions use a relatively dumb autocomplete, while VS knows the types of everything and shows you all of the things you can access and nothing you can't, including changes that haven't actually been compiled yet.

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.

YouCompleteMe (a vim plugin) uses clang to understand C++ code.

I can definitely see the advantage in some cases of good breakpoint debugging with a nice IDE, but personally I like to see realtime what is happening while running the program and changing things around, without having to stop,break,continue and repeat this cycle which stops the flow.

But each to his own. And like answered already, the YouCompleteMe uses clang to provide intelligent autocompletion for C/C++.

> why there are still people that enjoy working as if their computers are using a 25 year old developer experience.

The carbon footprint is much nicer.

Q: How often am I editing a file that exists on a computer close enough to me that a GUI editor would be at all useful?

A: Rarely.

I believe that it is good that there is no winner. If you look at vim and emacs specifically their thinking is very different. I would say that with the best plugins, config and skills in the world you would not be able to make one as good as the other in the others corresponding strength. Each is a winner in their own regards.

I think we have 2 winners:

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

Never seen that before, that looks really interesting!

And then of course people like the spacemacs leader-key binding and port it back to vim :-)

https://github.com/jimmay5469/vim-spacemacs https://github.com/sunaku/vim-shortcut https://github.com/sthysel/vim-spacemacs

I should use that! I try to keep a vim config that is mostly compatible with my Emacs setup (for when I'm remotely logged in to a place that has my dotfiles, but not emacs).

Sure I know about tramp-mode, but sometimes having vim around saves the day.

even without going full spacemacs you can do what I do, install evil, have it set to emacs editing by default, and set up a keybinding to go into vi editing (I use double-caps) it's awesome and really best of both worlds

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

According to Wikipedia (https://en.wikipedia.org/wiki/Vi and https://en.wikipedia.org/wiki/Emacs) both vi and Emacs are from 1976. 40 years this year!

To be fair, vim is not strictly vi although they were related.

Amazing, I was 1 year old when both were started. How many other software package has such longevity? Unix and its various guises?

Not quite as old (circa 1978) but TeX is still alive and well: https://en.wikipedia.org/wiki/TeX

Moreover, TeX has no serious competition (at least in the niche of typesetting mathematical documents). There are plenty of good text editors and IDEs to go around.

What about groff?

How does groff do formulas?

Using separate programs like eqn. (http://www.kohala.com/start/troff/v7man/eqn/eqn2e.ps)

Sorry, but eqn is just not in the same league as LaTeX. It's okay for simple equations, but as can be seen from the document you linked, it produces awful output as soon as the equations become a little bit complex.

Take a look at http://download.savannah.gnu.org/releases/lout/lout-3.40-use... (page 148 and followings).

Lout (http://savannah.nongnu.org/projects/lout) and troff/groff (https://www.gnu.org/software/groff/). Both do equations quite well, I would even prefer lout (it is a way more comfortable than LaTeX), but the lack of additional packages makes it inferior. Troff is older than TeX (not sure how old is eq package).

SPICE is even older, and still used: https://en.wikipedia.org/wiki/SPICE

Make is from 1977. GNU Make is somewhat younger.

NetHack is special for me in that it is a game that is in development since 1987, and is still fun to play.

AWK is from 1977 and I use it almost every day.

I actually love writing programs in AWK. I use Python for that kind of work now, and AWK is relegated to one-liners, but there's something very satisfying about the way programs fit together. It's like playing with Lego.

I have a better question. Will those tools be still used in 40 years? And what modern tools will be used after that time?

As long a there are keyboards, there will be Vim.

This is the most beautiful thing I've read all day.

Let's hope not.

Hey, why the downvote? I respect the good work that has been put into emacs and vim over the decades, and the good kick-in-the-but that spacemacs and neovim provide too.

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.

I use these editors for so much more than programming. I'll often have a buffer open just for scratch notes and org-mode for my todo lists. I've written papers for school using LaTeX in emacs too.

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.

Paredit is a textbook leaky abstraction. I find the experience very jank because of it.

how so?

I like the idea that people who want to use things will be able to continue using them in the future. Nobody is forcing you to use them.

Of course I don't want to actually force people to change---that would be a very hollow sign of progress indeed! The hope is something else become vastly more common without anybody being coerced.

Today's IDEs are clearly not superior in all respects, or emacs and vim wouldn't have the usage they do. I hope whatever comes next can be more uniformly better.

I think the down vote is that we see your comment as: "vim & emacs are glorified notepads". At least that is what went thru my head. But they are so much more than a way to type text, with emacs (which I don't grok) I manage my emails archive via gnus/mu/Maildir. Or do "Literal DevOps", check this out for something that still blows my mind with awesomeness: http://howardism.org/Technical/Emacs/literate-devops.html

>Unix and its various guises?

Most of the UNIX userland is from then, though it has seen rewrites (including clean room ones) through the decades.

Not very related as it is not a software implementation, but I also find it fascinating how FORTRAN, the first notable programming language is still used today by many after 59 years of its inception.

> To be fair, vim is not strictly vi although they were related.

In the same sense, the emacs most people use is not the original one. Everyone uses GNU Emacs or Xemacs.

I considered that, but I thought it was fair to consider them one in the context of the history of vim vs emacs competition, especially since both the original Emacs and GNU Emacs were written by RMS.

vi is not Vim.

Vim stands for vi improved and started on the Amega in 1991 so almost 25 years old. Certain people still use vi which was an improvement over ed August 1969 (Though I have been known to use ed in scripts from time to time).

Nonetheless he is right. As far as I remember Vim is based on the code of an editor that was similar to vi, and not vi itself.

Vi is a standard not a specific implementation. There was an original Vi, but since it's a standard unix tool, it got cloned by everyone who ever made a unix clone after it was added to BSD.

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.

Interesting view. I've never seen vi as a standard. But it makes sense.

Technically something can't call itself Unix(tm) without vi(1) [0][1]

[0] http://pubs.opengroup.org/onlinepubs/7908799/xcu/vi.html [1] https://en.wikipedia.org/wiki/Single_UNIX_Specification

Well I made his short two word answer into an explanation.

I believe it was Stevie (a vi clone for the Atari ST).

If you ever wind up booting the OpenBSD ramdisk kernel (typically used for installation and system rescue), the only editor available is ed. Luckily, if you're reasonably comfortable with vi, you'll find that most of the 'colon commands' work, and the other commands are pretty familiar ('i' for insert, 'a' for append, etc.). If you're an OpenBSD power user, it behooves you to have a hardcopy of the ed manpage handy ;)

The OpenBSD ramdisk doesn't provide busybox vi?

But ed is the standard Unix text editor.

Nope. The OpenBSD ramdisk doesn't provide busybox anything. I just double-checked on 5.8. I also doubt that they'd ever switch to using busybox given their aversion to the GPL. They also have their own tool (crunchgen) that packs a bunch of binaries into a single "Swiss army knife" executable.

Actually it is.

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.

It's not dead, it's finished. It's got all the features of the original vi, therefore mission accomplished. Software doesn't need to be developed ad-aeternum to remain 'alive'.

>Software doesn't need to be developed ad-aeternum to remain 'alive'.

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 thought we were talking about nvi.

https://en.wikipedia.org/wiki/Nvi

Afaik, nvi actually doesn't have all the features of the original vi. According to Wikipedia, "The aspects of nvi that are still marked preliminary or unimplemented are, for the time being, likely to remain that way." Moreover, nvi had been developed for a little while after the various BSDs stopped syncing with upstream due to licensing issues after version 1.79. I honestly think the reason no one develops it anymore is because no one cares. It's good enough for use in emergencies, and beyond that, it's either good enough for the people who use it, or they just use a more featureful editor.

> Software doesn't need to be developed ad-aeternum to remain 'alive'.

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)

Underlying API/ABI's get deprecated and eventually dropped, dependencies reach end-of-life and need to be replaced, and so on.

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.:

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/vi/

So yeah, it's being maintained. That's why it doesn't rot.

Hey, if you want text in italics use asterixs.

     > *Software doesn't need to be developed ad-aeternum to remain 'alive'.*

becomes

> Software doesn't need to be developed ad-aeternum to remain 'alive'.

Fixed it, thanks.

vi works fine on my BSD machine.

You could say that Vim is an (implementation of) vi, but vi is not Vim.

(Not that this is an important issue.)

Edit: also, vi is not dead: www.archlinux.org/packages/core/x86_64/vi

>You could say that Vim is an (implementation of) vi, but vi is not Vim

No, it's a derivative project. However, in lots of distros, when one runs "vi" they are actually running "vim" (in vi standards mode).

Give it another 10 years and people will still be arguing over this, just that there will be more of them on both sides.

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.

That's actually the main reason I try to move all my workflow to emacs. Most probably it will be maintained 40 years more and the time I invest in learning to use it it's not going to be wasted.

Competition makes everything better :)

Actually I don't believe there will be never a winner between the vim-way and the emacs-way.

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.

Both seem to have found a local maximum for the "optimal programmer's editor" function.

>I guess we could be saying the same in 10 years about firefox and chrome

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.

Hopefully servo will be merged into firefox within 10 years

I doubt that would change anything. Even after spending tons of money on marketing and making big changes to the browser, Internet Explorer never reversed it's drop from 90% to 50% marketshare.

I imagine Firefox's marketshare dwarfs both vim and emacs

Yet another reason why you can't compare the situation with Firefox and Chrome to Vim and Emacs.

Didn't Firefox just announce that future plans include moving to Chromium?

I went back to see if I could find where I read that and it was here:

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.

Judging by how this thread exploded, the discussion has shifted towards a standoff between two other groups. On one side IDE users shaking their heads at what they experience as a backward mindedness and on the other side Emacs/Vim/command-line users desperately trying to explain that there is a world beyond the IDE. There is unnecessary smugness on both sides.

I think emacs is fundamentally a better system but I'm using vim because that's what my computer could run better when I was 15 in the mid 90s.

Shackled by my past...

You might want to give spacemacs a try. It really doesn't feel like emulation. For me, it's been the better of both worlds. Ultimately, you'd have to learn some emacs stuff for sure, but you should be able to get day-to-day productive almost immediately.

Competition is great. I was kind of bummed that Bram didn't want to add support for asynchronous things in Vim and Neovim kind of forced his hand. It is great.

I have no plans to run Neovim in the near future, but I'm already profiting from it. Kudos to Tarruda and friends.

> And there is still no clear winner.

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.

To list few of the new features: Asynchronous I/O support, channels (Vim can now exchange messages with another process in the background asynchronously), Background jobs, timers, packages for plugins!

Wow! This is huge. So many interesting features landing on Vim 8.0.

Async I/O, plus JSON is seriously enormous. I'm very excited for how much faster things will be, and I can imagine JSON support will definitely make integration just that much easier. My one minor gripe was plugin speed, as syntax highlighting, linting, etc. can take long enough to be jarring.

Exactly!

Async I/O? In a text editor, where the bulk of the time is spent waiting for the user to do something?

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.

This is mostly about linters, makeprg's and things like Ctrl+P / Command+T, git-gutter etc.

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.

This is in fact fixing a massive pain point in vim, and one of the main reasons why NeoVIM has so much support. Saving a file in vim takes 1-2 seconds for me. Not because my disk is slow, but because I run some linters on my files, that take that long to all complete.

Async I/O is not about disk I/O, but communication with other programs.

I've opened 5GB files in Vim, on an average 2010 Ubuntu desktop. It took some time, like 5 minutes, but it worked.

Especially Syntastic. It's always a pain when every ":w" of a Ruby file hangs for 5 seconds during syntax checking because Ruby is so abysmally slow.

Five seconds?! Mine hangs for at most half a second (and I thought that was a lot). I almost don't even notice it anymore.

I get long hangs (5 secs) when saving Ruby code.

I think it just takes a long time to load up all the gems rubocop relies on, then to process the syntax. I put the blame squarely on Ruby, not vim.

Let's say these are five perceived seconds. The number might or might not be skewed by my passionate hatred of Ruby.

Yeah, Syntastic is my number one offender. I'd love to see Syntastic be able to just maintain a background server linting process (or several). I can imagine that alone, skipping all the environment loading/code parsing, would likely be good enough to make all but the longest files lint fast enough to be unnoticeable.

(Still worth it by far, though. I'll take a few seconds and nice error highlight over an hour of "Where the heck is my missing semicolon?")

> Asynchronous I/O support

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)

Yes it was. And now Vim is getting those features as well.

Are they merging code from neovim, or is it a parallel implementation?

I think the former---from what I've heard neovim and vim are on very good relations, and here is the fruit of that.

Negative. NeoVim does away with supporting the ancient systems that are important to Bram for some reason. I seriously doubt they will merge.

Good relations =/=> must plan to unfork, at least in a post-git world.

Parallel. Bram (Vim maintainer) doesn't seem to like Thiago (Neovim lead dev).

Well except for the code cleanup and the more extensive scripting options ;)

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.

I have a mixed feeling as a NeoVim user and long-time Vim user.

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.

Can you point me to the source of ST3 going open source?

It's not.

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.

I'm not a NeoVim user, but I've been on the edge of becoming one for a while.

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 think neovim is embeddable?

I'm pretty sure SolidOak just embeds neovim: https://github.com/oakes/SolidOak

As far as I know the NeoVim GUI apps[1] use msgpack-rpc[2].

[1] https://github.com/neovim/neovim/wiki/Related-projects#gui-p... [2] https://neovim.io/doc/user/msgpack_rpc.html

I alternate between Emacs and Vim every 5 years or so. Emacs gave me superior customizability using a "real" programming language: elisp. Vim, on the other hand, offers a faster, more efficient editing UX. The older I get, the wider the spread becomes between the speed of my thought and the rate at which I can input editing commands into the terminal. Vim allows me achieve higher efficiency and to almost "think ahead" by quantifying my movements and jumping to specific tokens in known locations. That to me has become more important lately than scripting in a nicer language than viml.

All of the new features of Vim are super nice, but I'll still primarily use it for the terseness of its editing UX.

You may want to consider looking at Evil mode, which gives you a very close approximation to the vim editing bindings in emacs. I've been using it as part of the spacemacs distribution for a while now and find it to be the best of both worlds.

Evil mode is slower than vim. And also you are in evil mode only during the editing phase. All other menus drop you back to default emacs keybindings and that is very painful experience. I used evil mode for a couple of years and still just went back to vim.

I have not found this to be the case with Spacemacs. Almost everything you need is bound to keystrokes using space as the leader key in the spirit of vim. As a long-time and fairly advanced vim user I recommend Spacemacs highly.

Don't you feel like you're pushing a square peg into a round hole? Or do you actually find yourself taking advantage of elisp in harmonious combination with Vim's editing UX?

In my experience it's cleaner than default emacs editing experience, but it's not as clean as you can get in plain vim.

I thought the same thing as you at first, as I was a vim+pathogen user. My workflow was working properly but to me it's just much simpler to do a SPC-f-e-d, add 'git' to my packages, then SPC-f-e-R and voila, git support is installed.

I'm sure I'll go back some day but for now Spacemacs is perfect for my use (i.e. writing small software, not large projects).

I was also using spacemacs for something like 2 month. After that I just rewrote my vim configuration with what I learned from spacemacs in mind. It's great and clean. But it's still emacs and vim emulation. Nowadays i'm much happier with my vim configuration partially thanks to spacemacs.

Can you share the things you took with you? I'm always interested in spicing up my vim experience.

Mostly key bindings. Space as a leader. Everything themed by prefix. Like <spc>mee to eval clojure form in repl. <scp>mek to show clojure documentation. <spc>cl - comment line. Switched to unite. Duplicated most used things from helm in unite. You can check out my github repo with vim configs at Gonzih/.vim on github.com

Personally my muscle memory adapted to this discrepancy, just as it did when starting with Vim (I started with Vim about 10 years ago and moved to Emacs+Evil about 3 years ago).

Now I'm somewhat the opposite, I expect everything else to have Emacs bindings, except when I'm directly editing code.

Spacemacs does a good job of _not_ dropping you back to emacs keybindings, though on occasion it still happens. I've not yet worked out how - my only recourse as someone who has never used Emacs without Spacemacs in Evil mode is to restart it...

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.

Dropped the support for MS-DOS. It was too big to fit in memory.

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] https://www.emacswiki.org/emacs/EmacsForDOS

[2] https://en.wikipedia.org/wiki/MS-DOS_Editor

Note that this is compile-time. It might still cross-compile.

My head turned around. I read it like Vim loads MS-DOS, and I thought, why would it do that? But then it occured to me dat this means Vim can run under MS-DOS. It's been so long since I've used MS-DOS as OS, I can't imagine it anymore. To me it's just a program that is run by another something.

Vim _cannot_ run under MS-DOS. It hasn't worked for years, that's why Neovim removed DOS support 2 years ago. The cries of "losing compatibility" were uninformed fear/uncertainty/doubt.

Vim also doesn't run on OS/2 and other platforms, though the Makefiles have not yet been removed.

Last time I used MS-DOS productively was in 2008, for a lab course while studying physics. The specialized equipment they used came with a software that ran under MS-DOS, and from that point, they "never changed a running system". I've been told that this particular PC has still been in operation at least one year ago.

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.

Frankly, everything OS it supports should be re-evaluated for support. A lot of cruft could be removed if Bram would make a break and say "We are dropping these at Vim 9".

> I don't really understand the culture of all the > customisation/plugins/etc. around text editors

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.

Been using Neovim for about 6 months now, The only real difference I have felt so far is that I was able to remove a few lines from my .vimrc, like history=10000 as Neovim does this by default. As for Vim, I am done with it forever, not because of vim more because of package managers compiling vim without paste mode or lua/ruby support and making me compile vim from source with my own flags, which was a harrowing experience for me, when I was just trying to set up my development environment.

Do you ever have to vim somewhere where there is no nvim? Like on a server, etc? I worry about getting used to nvim features or behaviors that might not be compatible with vim (are there any?) and being super bummed on a server some day!

Installing neovim is easy, so just install it there too. Not using a superior product because you might have to install it is an odd decision. Besides, I understand many distros are prepared to include neovim.

Servers often have vi installed by default, but that hasn't made me want to give up vim features.

I use nvim to compile code in non-ui thread.

Others have provided good answers but I'll add my 2 cents. Neovim was made to be fully(Mostly?) backwards compatible with all Vim specific features, and most Vi features. You may be wondering what is missing, some ed features and support for some more obscure Operating Systems. You shouldn't have to worry about the missing features as they are mostly legacy features that mostly all new/newish users of vim never will use. As for additional features they are mostly all under the hood, better embedablility, extensibility, and sensible defaults things you don't need when editing your Appache routes on the server.

> Plugins keep growing and more of them are available then ever before. To keep the collection of plugins manageable package support has been added. This is a convenient way to get one or more plugins, drop them in a directory and possibly keep them updated. Vim will load them automatically, or only when desired. See |packages|.

Is this going to replace pathogen?

Pathogen: Most likely. Vundle: Probably not.

And... there goes a lot of energy to neovim.

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.

From what this initial view of Vim 8.0 looks, it actually went in the direction of Neovim, the asynchronous inner works were what made me try Neovim in the 1st place.

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.

Neovim also has the terminal buffers, which Vim has explicitly stated to never add.

(Source: Somewhere in :help, but unfortunately I can't find it right now.)

Well, from my previous not great experience with terminal inside Emacs I don't really need that. I would be much happier if Emacs and Vim just had correct color support in the console so that I could use both from the console in a Tmux terminal and have a real terminal open side-by-side with the editor.

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 don't personally use the terminal support. Except it turns out that I actually did, implicitly. I use fzf for opening files, and I noticed recently that it's not actually 'integrated' into neovim, it just spawns within its terminal emulator. I tried fzf in vim, and the result was less than satisfactory, to say the least.

<rant>

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>

There's an option:

./install --no-update-rc

> from my previous not great experience with terminal inside Emacs

: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.

Don't forget true color support for those sweet colorschemes!

True, forgot that one and it's really cool to be able to use Neovim in the console without breaking my head over the colorscheme.

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.

Yeah, it would be nice if vim supported that natively, but it's possible to work around. My color scheme has lines of the form

    call High#Light("Comment", "italic", "bg", "#003300")

with a quick and dirty function that maps to the current terminal's supported colours. http://pastebin.com/3jx1i75L

This release is a poster boy example why competition is good.

Before neovim: Asyncronous operations? "Absolutely impossible"

After neovim: Asynchronous operations? "Why, of course, here, with a cherry on top"

Can somebody tell whether the API for those features also in neovim is compatible to vim8? Anyway, it's great to see that neovim provoced new developments in vim.

Not really.

By the way, I have a question: what is the best learning material for intermediate/advanced Vim users? I know quite a lot of Vim features but apart from vimtutorial, I never learned them in any organized way - it was more of a bunch of tricks I found via googling. It would be nice if there was a book (preferably free) on this editor.

I think if you are at a level where you can comfortably use vim, the best way to learn is to just keep using vim. Whenever something feels slow, or repetitive, look online for a solution or suggestion. Then you just use it until it's learned. I don't think any advanced tutorial would be useful, since it will be a collection of very specific things done by the author of the tutorial. I wouldn't be able to remember things like that if I'm not actively using them and finding them useful for me.

http://learnvimscriptthehardway.stevelosh.com/

Great book. This in combination with: a) the Drew Neil vimcasts and; b) Tim Pope's pathogen system and; c)NERDTree helped me to get to a point where Vim does most of what I want.

I make a list for things I know would be faster if I knew them and go on.

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

Since I happen to have the answer to both of those:

`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).

If I want to put parens around a word I do, ciw()<ESC>P (change word pulls it into the default register, insert the parens and then paste from the register back between the parens).

You can use the same pattern for any selection you have visually highlighted, such is the wonderful power of vim.

Handy trick. Thanks!

Nice use of the buffer. Is there a nice hack to remove the parentheses around a word as well?

I guess you could do a similar thing: ci(<backspace><delete><esc>p

ca( would work for this as well.

If you have the cursor just before the area you could do: 'dt)' meaning delete to next ), or 'ct)' to delete until next ) and the drop into insert mode. Learning word objects in Vim for me is one of the killer features, and one thing I miss in Emacs.

Take a look at vim-surround, which adds mappings for a lot of things like this.

vim-surround is the bee's knees.

`cs"'` change surrounding double quotes to single

`dst` delete surrounding HTML tag pair

`ysiptp>` wrap this paragraph in <p></p>

What's the difference between bdw and daw? I already use "b", "e", and "w" quite a lot, so the "a" and "i" infixes seem a little redundant. Is there an advantage to the infixes that I'm not seeing?

The 'a' and 'i' in this context operate on text objects. They're much more powerful than motions. For example, beyond the 'w' for word, there is 'p' for paragraph, '"' for double quotes. All of these allow you to edit the object while the cursor is inside them.

Interesting. I'd have to use ?" and /" for double quotes, although I do have () and {} for sentences and paragraphs. I'll have to go back to the documentation -- I suppose there's a "whatever is within the current pair of parentheses" text object? I could see using that quite a lot.

Try doing `cas` (change a sentence) or `dib` (delete in brackets), and on and on for all your different text objects. This infix notations are not redundant, because they are not motions like `b` `e` `w` are, but adjectives to be applied to the nouns which are text objects.

It looks like I need to learn what the text objects are. I learned vi about 20 years ago, and I've been using vim like vi ever since.

> deleting word while curser is in the middle of that word

: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

You can then surround whatever text object you want. Surround the current word with `sw(`, surround the current braces with `s{(`, etc. The `sv` prefix lets you surround the thing you just surrounded: `sw"sv(` turns `wo|rd` -> `("wo|rd")`.

My path from intermediate to advanced (and I think there are big differences in vim between these two) was by watching Derek Wyatt (https://vimeo.com/user1690209/videos) do his magic, and reading articles here as well as on reddit. From time to time there are cool blog posts with new things to try. It's also worth to read the source of some of the more famous plugins together with looking up stuff on :help.

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).

I also like http://vimcasts.org/

As well as producing vimcasts.org Drew Neil has also written [Practical Vim](http://pragprog.com/book/dnvim/practical-vim) which is a great companion to Vim/NeoVim.

I particualarly like the way it teaches you efficient text editing without needing plugins.

:h usr_toc is really one of the best introductions to vim (after vimtutor), I am surprised that not that many people seem to know about it.

Get a pdf of it here: http://www.eandem.co.uk/mrw/vim/usr_doc/.

To piggy back on this, in general how do you balance the time between switching out a toolset vs doing development work? For example, I've been using PyCharm for years but the switch in JetBrains's licensing strategy has me looking at Vim or Neovim. I use Vim from time to time just as a quick editor but I really need to sit down and learn it inside out to make it a useful tool for me. Is this something where you start incorporating it into each project or is it a situation where you just sit down with the tool for a few days and learn it inside out? Curious about people's thoughts on this.

http://vimgolf.com/

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.

The user manual is great, although admittedly not a very pleasant reading.

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.

Does vim have a roadmap/milestones or anything like that (i.e., anything that allows me to track the development process)?

A document? Nope. You'd have to lurk on the mailing list.

Why is there just 1 contributor listed at https://github.com/vim/vim?

It looks like the author takes patch submissions and applies them, rather than pull requests being merged. Detailed in: https://github.com/vim/vim/blob/master/CONTRIBUTING.md

Wow, that's pretty lame. No one gets attribution for their work.

He does put the name of the contributor in the commit message.

Ah, you're right. I only looked at a few patches in the log:

https://github.com/vim/vim/commits/master

And most of them don't have a name.

Async is massive. I have been using this feature heavily in NeoVim for the last 6 months.

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?

With the age of their respective codebases, I'd love to know what lurks beneath? Immaculate, well factored code? A hornets nest of hacks - what do you expect from such old codebases - or have they been re-written so many times you'd never guess their ages from the codebase.

Vim's codebase is known to be one of the most unclean collections of C code out there. It's one of the reasons why Neovim came into existence.

Pfft on immaculate, well factored code. All glory to battle hardened code that does the business everyday.

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.

Vim code predates a lot of modern best practices. It's not all cruft a la Spolsky's blog post. Some of it is just goo.

I completely appreciate that. 'Tis always a case of striking a balance. Even battle hardened code with countless edge-cases can be well factored. A system programmer whose opinion I trust greatly recently advised me to look at the postgress code for well factored, battle hardened code. I've heard others suggest that libgit2 is similar. I don't feel confident / qualified enough to comment.

I'm quite a noob at 'nix, so I tend to use nano whenever I need to edit something. Not sure if this is the right place, but could somebody explain the added benefit of spending the time to learn to use vim/emacs? I've tried vim, but it seems very complicated.

As a non-professional hobbiest, the biggest impact I can recall is that "vi" is universally included in every distro, while nano is not.

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.

The added benefit for me are, staying in the terminal where I do more than just edit, normal mode makes file navigation and text manipulation an extension of thinking, fast file switching, cross platform consistency, and a low maintenance burden (though the initial learning curve/setup is steep).

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.

Like other comments have said, learning one tool which is available basically everywhere means you only have to put in the up front learning once.

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 :)

This article is what convinced me: http://www.viemu.com/a-why-vi-vim.html

I learned vim 15 years ago because I saw its history and realized that if I learned vim, I'd never need to learn another editor's key commands. If you're not going to be programming, spending 20ish hours learning the intricacies of a text editor probably won't get you a return on your time investment.

Personally, I find vim's modal editing to be very efficient. When starting from a clean slate, it doesn't really matter much -- but when changing/editing existing text/code, I find it feels much more natural. It also works well without using the mouse, which is important to me because of carpal tunnel syndrome (and also helps when working without a proper mouse, such as on laptops).

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

It took me a week to get up to the speed of editing that I had with my former editor (gedit or so) and from then on my speed went up.

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.

What does it mean to NeoVim? Does it affect it's development, split developers or anything? Is it good?

I have to think it's a direct response to neovim, and that competition between them is likely to be very good

The reason neovim was started was to add these exact features. Now that vim has them, I think neovim's work is done. Mission accomplished.

Replace Neovim with Chrome, Vim with Firefox. Does your argument still stand?

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.

Ehh... I think neovim was also started to create a decrufted version of the vim codebase. That goal is still perfectly valid.

I've been trying to evaluate the different editors.

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.

The problem with evaluating editor efficiency is that you are more likely to measure the user's proficiency. The vim editing style is only as efficient as the number of motions that you know. (I use about half of them actively, but I have a lot of vim users sitting around me that barely know "w".)

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. :)

Yes, but there are a number of people that have gone though periods of using one and then the other. I have, at least anecdotal, experience with both.

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.

I recall seeing a study that concluded with mouse/gui-based editing being more efficient, even if users felt more efficient using vim. You might want to look at ACME[1].

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

Has anyone ever run :help iccf?

Remember to donate to uganda guys it's the only thing Bram asks for in return for this software.

Best thing to come out of this is async support.

https://github.com/vim/vim/blob/master/runtime/doc/version8....

There doesn't seem to be documentation for the new packages feature yet. I'm curious if this is actually intended to obsolete the current ecosystem of vim plugin managers.

I really like those improvements and features. Specially the Async/IO stuff, jobs, timers, and a stab at plugin packages.

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.

For Xcode users out there, XVim has been a game changer for me https://github.com/XVimProject/XVim

Soo, are these changes already in the git repository? Because the readme is still pointing out that the repository is for 7.4 and the tags/branches are not very helpful. Did I miss something?

The new breakindent options sounds very useful. I've run into the same issue from time to time. This hasn't been possible to fix before, has it?

Does anybody know what native feature is missing in Vim that makes Ctrl-P (with all optimizations) slower than Emacs ido-mode?

Not a real answer to your question, but for the last number of years I've been using Command-t (https://github.com/wincent/command-t) and after the initial index operation, it's super quick.

Command-t requires Ruby support in Vim.

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.

Have the various plugins started to make use of the new async/jobs/messages functionality already?

The asychronous IO, Channels, JSON, and Jobs are HUGE. This will be a game changer in so many ways.

So, if I had waited nine more hours, I would have gotten a lot of upvotes, I guess.

See https://news.ycombinator.com/item?id=11484697

Is there a way how I can copy blocks of code outside the vim window to another application without also copying the line numbers?

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.

:set nonumber removes the line numbers so you can copy without them

no, i do not want to disable line numbering. I want to avoid to copy them. I do not want to switch line numbering on off for every copy process. Absurd idea.

A better option would be to use a plugin that yanks text to the system clipboard.

You don't need a plugin for that. Just set the 'clipboard' option.

Note that you need Vim compiled with +clipboard for this to work (or +xterm_clipboard if you are using X11)

> Is there a way how I can copy blocks of code outside the vim window to another application without also copying the line numbers?

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-...

a good example for a stupid limitation and the enprmous waste of brian power just for a very simple thing. Have to start studying and doing real research for the most simple features. Waste!

So fix it permanently or stop complaining?

Ideally, Vim is a tool you'll be able to use for the rest of your life, so an upfront cost in learning it is a cost that becomes small when measured against the time scale of your career.

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.)

Agreed. Vim is one of the best investments in learning I've made to date.

Very true. I hand-compiled and memorized my own vi cheat sheet decades ago, and it has paid off very well. It's systematic, as many tutorials point out, which helps a lot.

most terminals support "rectangle copy" - just keep ctrl pressed and you can select a rectangle from whatever top-left starting point - easy way to copy only content without deactivating line numbering.

There are plugins for that. Check out vim-easyclip, and for comments theres vim-commentary(barebones) or nerdcommenter(loads of advanced features).

too many keystrokes, checked that.

:help :map

>Is there a way how I can copy blocks of code outside the vim window to another application without also copying the line numbers?

:set nonumber

If vim causes you to write comments that go from "How to I copy and paste correctly?" to the last 3/4th of it being "Programmers are fucking stupid" ... it might not be the tool for you.

    vnoremap <C-c> "+y

Just a minor nitpick, vnoremap creates a mapping for select and visual modes. You should use xnoremap as that's restricted to visual mode only.

Select mode is used by snippet engines mostly, and you don't want this mapping to affect select mode.

will update my .vimrc to reflect that, thanks! nitpick appreciated

Normally you should be able to yank the lines you want to copy to the * register (check :registers). The * register is basically the clipboard. You can use it to copy stuff from and to Vim. It does not necessarily work under every OS, but so far in Windows and OSX it worked fine on console and GUI.

For commenting and uncommenting you can check the NerdCommenter plugin.

Ctrl-V to turn on rectangular visual mode, select the area you want to copy (presumably you understand to not select the line numbers), then "*y to copy it to the system clipboard. Once it's on the system clipboard, you can then paste it into another application; generally this is done with Ctrl-v or something similar, but you should check your operating system's user manual to verify this.

Perhaps you should try watching some screencasts with experienced vim users editing text, the speed they can achieve and the level of precision is almost impossible in any other editor.

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.

Your comment is nothing but a rant. There is no constructive criticism, only you venting your frustration and anger while calling names and lashing out at anyone within reaching distance. This is not an effective form of communication. I would suggest that you figure out a better way to deal with people if you want them to help you figure something out.

[And not all programmers use Vim or Emacs. Programmers are people, and like all people have differing opinions.]

>Is there a way how I can copy blocks of code outside the vim window to another application without also copying the line numbers?

    set clipboard=unnamed

On Windows at least, that will make Vim use the system clipboard as its default register (the one you yank or paste from when you don't explicitly specify a register). Alternatively, you can yank and paste from the system clipboard like you would from any other register:

    "*y<movement>
    "*p

Reply on news.ycombinator.com