(you find following passages later in his post and they don't reflect my opinion)

> A design goal of Kakoune is to beat vim at its own game, while providing a cleaner editing model.

> Kakoune manages to beat Vim at the keystroke count game in most cases, using much more idiomatic commands.

> Kakoune provides an efficient code editing environment, both very predictible, hence scriptable, and very interactive. Its learning curve is considerably easier than Vim thanks to a more consistent design associated with strong discoverability, while still being faster (as in less keystrokes) in most use cases.

This example was a bit silly: "dtf will delete to next f, if you then realize that was one f before the one you targeted, you need to undo, go back to your initial position, and try again with d2tf."

There's no need to undo. Just follow up with a dot and you're done. Which pretty much illustrates my other general strategy, which is to edit incrementally without worrying about getting each command perfect.

(Which is not to say I don't find Kakoune intriguing.)

Edit: the yank example is actually way better, because you don't find out that you did something wrong until you go off and paste it somewhere else.

   mmffffy`m

   Ommffffy`m^[0"wDdd

   @W

You can of course use vim's visual mode, but in this simple case, there's not much difference.

With practice, it's more like finger memory than cognitive load. What he's doing is setting a mark named "m", going to the second "f", and yanking from there back to the mark. It's a fairly interactive sequence as you move the cursor around, so while it looks scary in print, in practice it's just a series of actions you don't think about much.

An advantage to using commands like this is that you can record them into macros with just a couple extra keystrokes as you go. I used to do a lot of SQL and I'd get bored and frustrated, until I learned to use macros in vim to automate the repetitive parts.

Compared to IDEs, why not both? For languages with good IDEs I tend to use them with vim emulators.

In other programming I don't have particular favorite macros, but still find small repetitive bits here and there that can be turned into temporary macros. Say for example you have ten variables that each need to be reset to zero. Don't type all the resets, just type the variables, turn one of them into a reset while you're recording into macro w, then type 9@w to do the rest.

Copying up to the second f is just a silly example. It could maybe occur though if you were manipulating lines in a data file. You look at it, see that on each line you want to do something with everything up to the second f, so you make a macro. You don't save it for general use.

In short, macros aren't for major repetition that should be factored out, they're for the minor repetitive edits which, if you're not using vim, you might not even think of as repetitive. Sometimes they're useful for refactoring.

So no, I'm not using macros "without even thinking" and this would probably be a more productive discussion if you didn't make such assumptions.

Ah, but you can just name your indexes, so it's a[salary]. But now you've got ten lines of code naming each of the index values, and a vim macro makes it faster to write again.

In any case, macros are just one of the features that make vim productive. I find that I do a lot more small refactors when I'm using an editor that makes arbitrary edits really fast and convenient. It's complementary to the named refactorings you have in an IDE. If all you're doing is pointing and clicking then you don't need vim, but if you're actually writing code, it helps.

I used to use a vim emulator in Visual Studio, and it was great. Now I'm working with stuff that doesn't have IDE support, and I'm still productive.

A lot of good programmers are hooked on vim. Hasn't it occurred to you that maybe they have good reasons for that?

    employee = new Employee();

I guess I'm failing to make the point, so I'll just refer to the articles that got me to try it in the first place.

http://www.viemu.com/a-why-vi-vim.html

http://www.moolenaar.net/habits.html

While remembering long button combinations seems hard and tedious and "strain on cognitive capabilites" they really are just chained commands. In the idea world you don't think: "now I just have to hit v4w"+y to copy these things to clip board", but instead: "I'll copy next four words into clip board" and then just execute the commands. Same goes to longer commands, instead of hunting down some hidden feature in your IDE, you can just bang out chain of commands you wish to execute.

AKA a function.

> code editor is to be context aware and transform your code accordingly to the language rules, not just blindingly execute a series of commands

If you "blindingly" execute a series of commands in anything, it's not going to end well. Also, vim can load commands/plugins based on filetype, or any arbitrary condition you want.

Vim is older than Elvis, by years.

The FOSS BSD derivatives never got the actual Vi editor of Bill Joy ancestry.

While nvi isn't vi, it was intended to be "bug-for-bug compatible" with Joy's original vi. It's not quite there, but it is much closer than any of the other vi clones.

The FOSS BSD derivatives can have a vi descended from Joy's: `2bsd-vi` in FreeBSD's ports collection, `traditional-vi` in OpenBSD's ports collection, `ex` in NetBSD's pkgsrc collection. Or anyone can nab it from http://ex-vi.sf.net/ ;)

So in this case...

vtfd

is one more keystroke, but you see what you're deleting before you delete it, so if you need to the next f, you can just smack semicolon until you get there.

vtf;;;;d

(semicolon repeats last "t" or "f" movement)

Otherwise, yeah, dot is great. I love using that for repetitive stuff on "tabular" copied entries that I'm not thinking real hard about transforming. (E.g. - 5 lines or so that I'm not cooking up a regex or an perl/awk spell to transmute)

   > The dot trick is fine, unless you wanted to paste the 
   > deleted text somewhere afterward, in which case you 
   > need to pick it up in one go.

   "1p.

My ignorance is showing. Is there a stack of yank buffers??? Does this p-for-put pop the top buffer, back up before the inserted text, then .-do-it-again and put the delete/yank beneath the last one on the stack? I have no idea what the quotation mark actually does.

Thanks in advance if you can explain how that works to me.

Having said that, if you like both vi(m) and the structural regular expression support of sam/acme you might be interested in vis which combines the two:

https://github.com/martanne/vis

Mind expanding on that, or are you just going to whine? It's not like vi is the ultimate tool.

I'm not convinced I'll switch to Kakoune (as I've got a lot of momentum in Vim, not just with the editing language) but the automatic display of the _semantics_ of your current chord is an interesting idea.

> Kakoune’s grammar is object followed by verb, combined with instantaneous feedback, that means you always see the current object (In Kakoune we call that the selection) before you apply your change, which allows you to correct errors on the go.

Let say I want to delete a word from somewhere in the middle of a line. I would then navigate to the line in question, then press something like "^wwwdw" (i.e. "move to the beginning of the line, move 3 words forwards, delete word"). The motion of the deletion is the same as the motion for navigation. How would that work if the motion comes first? Would I go "wwwwd"? Would that delete one word, or four? Would you use a different key for the motion and the text object?

I don't think this is a bad idea, swapping the order. The thing about showing you what's about to happen is a great point (though Visual mode in vim works pretty well for this purpose). I'm just wondering if it's better in practice. I'm certainly willing to give it a shot.

'w' will move the current selection to the next word so only one word. To extend the selection you need to press 'W' so "wWWWd" will delete four words. For most motions (if not all), the uppercase variant will extend the current selection.

This also makes searching slightly different:

  / search forwards 
  ? extend selection forward
  <a-/> search backwards
  <a-?> extend selection backwards

https://github.com/unblevable/quick-scope

I think you've hit the nail on the head here. c3w in vim is 3Wc in kakoune, 3wc will change the third word, straight off the bat there's a lot more shift key hitting. The most annoying thing though is getting the motion wrong, if 3W turns out to not be the motion I want, hitting escape does not return the cursor to where it was before the motion.

We can truthfully keep designing 2D editors (and we will always most likely use them to some extent) but I believe it is more important to consider different UI paradigms altogether.

For instance, what about editing a living code environment? Game development is very immersive: you can manipulate a running environment and see results immediately. How can this be extended to other development tasks like server-side development?

What if, when you select a for loop from code fragment a 3D visualization of the programs data structures at that point is shown to the user. What if you can, instead of launching a debugger, run the debugger as you're writing the code and step forward and back and see these visualizations change?

We have all the technology. It's time to get to the next level.

I run a Vive on linux. Which required my own stack. Which took excessive time, and is limiting, but has some road-less-traveled benefit of altered constraints. So I've gone to talks, and done dev, wearing Vive with video passthrough-AR, with emacs and RDP, driven by an old laptop's integrated graphics. Yay. But think 1980's green CRT (on pentile, green is higher res). In retrospect, it was a sunk-cost project-management garden path.

There's been a lot of that. One theme of the last few years, has been people putting a lot of effort and creativity into solutions to VR tech constraints, only to have the constraints disappear on a time scale that has them wishing they had just waited, and used the time to work on something else. It's fine for patent trolls (do something useless to plunder future value), and somewhat ok for academics (create interesting toy), but otherwise a cause for caution.

So on the one hand, I suggest that if the center tenth of VR displays had twice their current resolution, everything else being current tech, we would already be starting on a "I can have so many screens! And they're 3D! And..." disruption in software development tooling. But that's still a year or two out. Pessimistically, perhaps even more, if VR market growth is slow.

In the mean time, what? Anything where the UI isn't the only bottleneck (work on the others). Or which can work in 2D, or in 3D-on-2D screen (prototype on multiple screens). Or is VR, but is resolution insensitive, and doesn't require a lot of "if I had waited 6 months, I wouldn't have had to roll my own" infrastructure. Or which sets you up interestingly for the transition (picture kite.com, not as a 2D sidebar, but generating part of your 3D environment). Or which can be interestingly demo spiked (for fun mostly?).

For example, I would love to be working on VR visual programming on top of a category theoretic type system. But there seems no part of that which isn't best left at least another year to ripen. Though maybe 2D interactive string diagrams might be a fun spike.

What about voice-controlled programming though? I always thought it would be nice to voice-control my OS. Not specifically for a text-editor, but as a general interface to the OS. It would be nice to move these features out of the cloud and directly onto systems. But then again, a lot of companies (amazon, microsoft, apple) probably don't want to encourage reverse-engineering of their intellectual property. We definitely need open-source variants.

Better AI chips with lower power-consumption and optimization for these types of operations will hopefully usher in a new set of productivity-enhancing applications!

https://www.jetbrains.com/mps/

You can do Google voice recognition in browser/WebVR, but it's better at sentences than brief commands.

Another component, largely unexplored, is hand controller motion. The Vive's are highly sensitive in position and angle. Millimeterish. So imagine swype text (phone keyboard continuous sliding) with 6 DOF. Plus the touchpad (the buttons aren't something you'd want to use all the time). Keyboard+pad is mature tech. But wands-with-pads look potentially competitive, and (not yet available) hand-mounted finger tracking added to keyboard+pad might make for a smooth transition. Plus voice. The space of steep-learning-curve input UIs for professionals looks intriguing.

Every few years, I make an attempt to learn to use one of the classic editors like vim or emacs, and inevitably give up after the enormous productivity drop I suffer when writing code. I just can't seem to pick up the muscle memory required to become fast with these tools, and the overwhelming array of customization options leaves me frustrated.

The most annoying thing is that I want to learn one of these, because I think I'll enjoy it once I do. Any suggestions from people who have picked one up on how to accomplish this seemingly Herculean task?

And, I suppose, I have another another question: is it worth it?

Keep using your 'main' editor for coding for now.

Get a shell/terminal that you can open/close with a hotkey (iTerm2 on Mac or something like yakuake on linux)

Run the editor you want to learn (I recommend emacs) in your hotkey terminal (basically you want an 'always there' emacs that you can just pop open at the press of a shortcut key)

Spend 5 minutes learning the basic commands.

+) Move the cursor around.

+) Open a file.

+) Save a file.

+) Switch between buffers/files

Now while coding in your existing editor, use the hotkey window with the new editor as your 'scratchpad' or diary. Note down ideas, todo items, thoughts about the code your are writing etc. Google commands as you need them and you'll pick things up bit by bit.

You don't see the productivity drop because you're not using the editor for your main task of coding, but you'll be using it 'little and often' which is a great way to pick things up.

I made the full switch when after a year or so at work I found myself pseudo-coding and stubbing out methods in my scratch file in emacs and copying them to my IDE.

YMMV but hope that helps :)

I personally found myself using vim a lot as, uh, some sort of poor man's one-shot data analysis/text reformatting tool among other things. What I mean is, quite often I paste in some semi-formatted text like logfile snippet (or open some data that is quite hard to process using shell and extensive piping if turning into csv/tsv and is painful to manipulate via dragging-and-dropping-and-cutting-and-pasting in spreadsheet software afterwards) to do all sorts of manipulations: I can use :s to replace things, or use macros with conventional actions like n3w2de, or bail out to :!awk, :!grep, :!cut, :!paste, :!column -t, :sort (or :!sort -nk123) if I need to format, filter, cut out some columns, sum over columns/rows etc. (I can even do |xargs!), or I can (rarely albeit quite ineffectively) use Ctrl-v to merge lines (if :!paste is not enough), or 'Ctrl-v I' to quickly type in something on multiple lines at the same position before processing any further -- all of that in any combination and with any selection. And I'm pretty sure I forgot something while writing all these things down before sleep.

I doubt if any other text editor or IDE could be as useful as vim in tasks like these, and now I also see this as a great opportunity to learn vim through googling for things one does not do every day (and does not know how to do) in any other editor, as these quite often will turn to be benefitial for everyday vim (or shell, or both) users. (However, it is also quite hard to me to imagine vast amounts of people with similar use cases, let alone people that would even consider vim as a tool that would solve their problems even with some time invested in it.)

The problem is the people who reply will be the people for whom vim and Emacs "clicked".

I'm like you, and when I looked at my vim using friends, they really aren't any more efficient. Also, while your editor will "work forever", expect interesting plugins (like C++ integration via clang) to be less stable than say atom or visual studio, and to have to nice plugins every few years.

Also, they don't fit well on a modern desktop. I use lots of apos, each best for their use, that all use the same shortcut keys. That's integration that I like.

Personally I would nominate emacs using spacemacs[0], but I knew both already going in. I have a hard time understanding what people find hard about Vim, but I've used it for 7 years now (well, spacemacs now), so I probably just don't remember what was hard.

I think it wasn't so bad for me because I didn't try to learn much about it. I learned how to move, (just the hjkl part), and basic selection. Anything else was learned "just in time."

For example, even after having used vim for 7 years, I never knew about the "ib" selector. Never needed it, and doing that sort of selection has never been painful enough to me that I went searching for a "better way."

While things like vim-tutor or vim-golf or whatever they have now might work for some people, that would have killed it for me. Learning for the sake of learning will get you part of the way there, but learning out of a personal need is what leads toward "mastery." And I define mastery in a restricted sense of being able to do what you want, fluently.

[0] http://spacemacs.org/

[1]: https://sanctum.geek.nz/arabesque/vim-anti-patterns/

If it matters, I don't think many people can program any faster than I can in Emacs, especially against macros, interesting plugins, functions, and snippets.

There is a trope about how a new Emacs user will be faster than most Vim users, but watching an expert Vim user work blows the best Emacs / IDE user out of the water.

I am constantly learning new Vim commands[1], and i feel i only know a tiny fraction of the vim editing language. Yet, i still love vim, and use it constantly, for everything.

The approach i take, as to make it enjoyable and not a job, is: "is what i am doing now annoying?". If you find yourself hitting j (to move down) 40 times in a row, or holding it to move down slowly, etc - Google for a solution[2]. It can be a little annoying in the beginning, but when you're starting out your far less likely to want to "fix" every bad pattern, and therefor you aren't spending all your time Googling. In my experience, you are only improving upon the things that most annoy you, and as time goes on, you improve quite a bit while not even trying.

[1]: discoverability is not it's strong suite, which is why i'm going to try Kakoune. [2]: You can multiply the command (40j), or <Ctrl-f>/<Ctrl-b> to jump. Among other things.

Macros are immensely useful themselves and everyone should learn and use them, but they have another benefit beyond simple utility - writing good macros requires using commands that generalize rather than "eyeballing" how many times you should press a key. If you want to move to the next paragraph in a macro, you can't just mash j until you're there because every use of the macro might require moving a different number of lines. What you can do is use { and }, vim's built-in commands for moving by paragraphs that are underused because holding down j is "good enough" for interactive use. I find that after I start using a command to make better macros, it filters into my interactive use soon after.

As a bonus, using more powerful motions instead of repeating weaker motions makes your macros execute a lot faster.

Sometimes a mouse is faster.

I used vi for a few years then switched to emacs, which I used for around 15 years. I "lived" in emacs - terminal, web browser, email. Everything.

Now I only use JetBrains IDEs, and have no desire to go back.

At some point, you realize that software development involves way more thinking than it does typing.

(Although, some of the reason I switched from vim is that I have been using an Alphagrip keyboard for a while now and mouse/arrow keys are always available _right now_. It really changed how I interact with software.)

I'm an (inefficient) vim user. I learned vim because I didn't want to ssh into a terminal and type nano. For this purpose learning an editor that is shipped with every (?) unix-system is amazing. I don't know if emacs is also shipped with every unix-system, but learning the basics for the sake of configuring servers is quite handy. I also loved Sublime Text, so I combined using vim and Sublime Text as my main editor.

However, when learning node and writing good javascript I noticed that my debug cycle was very slow. It was so slow that I noticed that I was debugging 80% of the time and writing code about 5 to 10, and thinking about code 10 to 15. So in my case getting a good debugger was a lot more important than having an editor with which I can whizz through text.

So for node.js I switched to Visual Studio Code.

For me, I learned vim & touch typing at the same time. Generally I learned while doing side projects, supplemented with general vim sessions (such as the built-in tutor, and http://vim-adventures.com/).

Many find it easier to start off with GUI vim as your favourite keyboard shortcuts are still there, but I found that too much of a crutch. Once you commit a few standard sets of motions to muscle memory, I don't think you'll find that much holds you back in day-to-day typing. If you notice yourself doing something repetitive when editing, go and look up how to do that thing more elegantly, and carry on.

I'd also just ignore all the customisations until you find yourself at least somewhat productive with the 'factory settings'.

No other tutor stuck for me.

I really like the out of the box completion vim has where it completes against words in files you have open. Most of the completion I need is long variable names or functions/modules and if it's not in the same file I'm editing I already had it open in another buffer.

That and a basic PEP8 linter work just as well for me as any of the major IDEs I've used.

To start off I used no addons at all, and didn't use any for probably a month or two. I'm a front end developer and spend most of my time in Javascript and Rails at home to give you an idea of what tasks I'd do in Vim.

Eventually I started to notice things I found hard in Vim and slowly set about finding some addons to complement my usage, maybe just two or three at a time. I still probably only use about ten addons so it's not too heavy.

Was it worth it? I'd say so, I'm still learning but I can do most things without using the keyboard although I'm certain there are more simple and elegant ways to do things in Vim heh.

Oh and the best tip I heard? Don't place anything in your .vimrc you don't understand.

If you can't afford that during your productive coding hours, you'll need to set aside dedicated time to be productive at learning - time when practicing vim or Emacs is the only goal. Run through vimtutor or the Emacs tutorial (Ctrl-h t) to learn the basics, then run through it again. Repeat until you can do the tasks without reading the parts explaining the commands.

Grab a random long file of code, make a copy, open the copy in your editor. Practice navigating - pick a character on the screen, work out a fast way to get there without touching the keyboard, then execute it. Practice selecting words, bracket/quote-delimited chunks, lines, functions. Practice making small but precise edits. Get used to the different paradigm of cut/copy/paste that both use, including registers (vim) or the kill ring (Emacs). Practice using searches to move around, and also search/replace.

Learn how to use the built-in help. Both Emacs and vim have amazing help systems that cover every default keybind, built-in command and user-customizable setting.

Do all of the above without any customizations or plugins. After you've mastered the basics, you can start customizing, but try to only do it to fix pain you've already experienced rather than add things you might need some day.

After learning the basics, maybe find a subset of tasks to use with your new editor. For example, continue using your IDE for day-to-day, but edit config files with the new editor. Then go from there.

Emacs, IMO isn't like any other editor. You can't just install it and have it work for you out of the box. Another poster suggested that there would be people for whom Emacs and vi 'just click', but I don't think that's how anyone learns to use emacs. You need to customize the editor in order to make it useful. It's not about memorizing key combinations (that'll come with use over a long period of time), it's about employing the ridiculously powerful tools that come with Emacs or can be downloaded from the package repositories. With Emacs, you can do anything you want. When I first started using Emacs, it felt like I was laying siege to a fortress. Doing basic things like saving a file involved looking up a key combination. Now anything else feels not much better than notepad.

To learn emacs, I think that the best place to start (after giving up on the tutorial) is to read other people's init.el files. You can find these all over github. You should read through them and any customization or function that you think you'd like to have for yourself, copy (the key combination for paste is C-y FYI) that into your init.el file (~/.emacs by default). As you read through the init files, you'll find out more and more about what Emacs can do for you, and you'll build an editor that's comfortable for you. IMO, without a custom init file, Emacs isn't really Emacs. Treat it like a side project for the first month or so, and I believe that eventually you'll move over completely. Have fun!

IMHO the best bang for buck that you get with these editors comes from learning just a handful of commands for the most common stuff, i.e. open/close/save, move caret, cut/copy/paste/, switch between buffers. So with a more modern editor with emacs/vim like plugin you can have the best of both worlds, i.e. enable fast operations for the common stuff while also having sensible menus etc. for the non-common stuff. If you go "raw" emacs/vim, then everything is cryptic.

In that spirit, I'd say learning an editor with a steep learning curve just for the sake of learning isn't very effective - and that is probably the reason you end up frustrated. However, if you can find something else to learn within the editor - so that learning the editor comes as a side-effect - you'll progress much faster.

I believe this to be the reason I haven't been able to pick up Vim. Editors are tools - and if we see no use in the tool, we'll never get good at it.

I think the biggest gains in using vim are the small navigation, copying, and editing keystrokes, and that there are little to no productivity gains of using other vim features like tabs and buffers, over say tabs in IntelliJ / Sublime. I am a little biased but I really think that being quick with the vim bindings really makes me a lot more productive at editing code than my non-vimming co-workers. When we're pair programming, it's usually me who does the driving because in one or two keystrokes I can do something that would take them 5+ seconds with a mouse.

So just install the vim bindings on your favourite editor and start picking it up bit by bit. You can start simple with the h,j,k,l keys for navigation, and i for insert, and use the mouse for the rest until you get up to speed.

So far it has helped to work on a project that involves typing in source code that has already been laid out (its Douglas Crockford's essay[1] on writing a JS parser). Literally I'm just typing it into one file, making a few decisions about whether to put all of the factory functions at the top and have the instances at the bottom, etc. It lets me focus on:

  -Opening files
  -Saving (:w to keep the file open, :x to save and close)
  -Basic copy/paste
  -Navigating around the file
  -Switching modes

It's too early in my usage to say whether it's worth it or not, but I feel confident that being familiar with other text-editing 'paradigms' is a good thing.

[1] http://javascript.crockford.com/tdop/tdop.html

I know enough to use it, but not enough to like it.

For virtually all work where I don't have to use a terminal editor, I use Sublime/Textmate or one of the language specific Jetbrains IntelliJ derivatives. The "jump-to-declaration" functionality of Jetbrains is so smooth and so good that I actually have a hard time not having it available now.

Truly useful things get committed to muscle memory almost immediately.

  > If you do any amount of work via command line or SSH,
  > you need to be competent with one of them.

I always said that love for vim is an example of Stockholm Syndrome; and now I'm using it daily as my main editor of choice. The killer feature for me is :cex system('foobar | grep something | ...') | copen. Other than that, various plugins, especially for Go (vim/emacs/acme(?) have the most mature plugin ecosystem for Go) and CtrlP. My current opinion is that vim is in some ways super cringeworthy, but in other ways lightyears ahead of competition. And as to the Stockholm Syndrome... I'm kinda on the fence now. But then... isn't it actually what the Syndrome is all about?...

I learned vim for three month. After a vimrc of close to 150 lines, I had to admit that sublime text has more functionality than vim and all of them are far more difficult and slow to use (long and hard to memorize command names). It's even worst compared with IDEA.

Now I only use vim as my default editor in terminal.

Just use sublime, or even better, IDEA.

I'm an Emacs user and there is a good multiple-cursors package for Emacs which I also use, so I have access to all of macros, regex-replacement and multiple cursors. I find that I do use all of them, but in different situations. I think of multiple cursors as "lightweight, instant feedback" macros.

I often screw up macros because of little edge cases that don't occur in the location where I'm recording but do occur somewhere else I want to apply the macro. You don't notice the mistake until you run the macro at that other location! If you ran the macro many times, you might not even notice the mistake until much later. When I do notice a mistake, I undo and edit the macro so that it applies to the other location too and then rerun.

With multiple cursors, if I can see all of the cursors on the screen at once, I usually spot mistakes while I go along and fix them immediately. Macros are like the compile and run cycle, whereas multiple cursors are like using a REPL (even more like a Bret Victor style live environment). I always prefer REPLs for the same reason.

If I can't get all the cursors to fit on the screen at once, I typically use macros, but thinking much more carefully about the macros than I would with multiple cursors. If you almost never screw up macros multiple cursors might not benefit you. But then again they might, because they let you be sloppier and go faster.

If you have parts of code that share so much structure that multi-cursors are useful, you likely want to factor them out.

Switching between different editors on all platforms was a chore. Emacs provides me with the same basic functionality in all environments and for all languages I use. Additionally, it works very similarly both on the desktop and in a terminal, so I can use a powerful editor even in fairly restricted environments.

So yes, for me it's worth it.

I started with plain file-editing, with a focus on keyboard shortcuts for editing. When they felt somewhat comfortable, I started using basic modes (fill-mode for better editing, C and Python modes). As you go along, you'll find things you want to do (format paragraph, autocomplete,...) You'll look them up, and find that they are either built-in, or available as a mode. Rinse, repeat :-)

An adventure game using vim. May help you learn.

Absolutely!

--- When I got back into emacs I dedicated two weeks to re-learn it after years of not using it.

I watched/read a couple of tutorials for setting up a python development environment - which happened to be one of my drivers since I hadn't found a decent python editor.

I read through the built in tutorial once, and referenced it a few times in the following days as I was editing. I had coding to do, but I did manage to slim down my task list to account for the potential of lost productivity.

For emacs M-x describe-mode was very helpful in getting a list of chords/hotkeys, but the ones that I really needed to develop a memory for were navigation/search/save/exit.

It probably was the full two weeks before I was comfortable. Now I get into other environments and I wonder how people deal with how slow things are or how you are supposed to remain focused when you have to use your mouse all the time.

My favorite plugin is yasnippet. Quick and easy templates for repetitive tasks with multiple stop points and dynamic content.

After that, any effort is simply in googling what you need your editor to do. If it's not built in, somebody has already wrote something for it 90% of the time.

But each of those editors requires time to really learn, just like vi and emacs (formerly I was proficient in them too). Many people look at Visual Studio for example, see the Solution Explorer and just go "well, that must be the only way to open a file"...um, no.

In Japanese (書こうね), it translates roughly to "Let's write, mmkay?"

1) beat http://vim-adventures.com/

2) Turned on Vim bindings in intellij, can always just drop into insert mode when you forget something and do whatever as normal

3) Once I was comfortable with 2, switched to real Vim

4) Suffered a bit, but nothing terrible

5) Never want to go back

I also find the packages out there are pure genius such as ace-jump (originally from vim i know..)

but don't even bother for anything .NET or Java.

As a relatively new vim user I would say it is definitely worth it. I started slowly adapting the navigation just for fun and upgraded vim as my main editor roughly a year ago.

The thing why I personally like vim is because I can optimize every movement, every text change and every action to maximum. If something is not intuitive or feels awkward, I am one step away from changing my vimrc [0] to fix it. As a result, you end up with a editor that never forces you to leave the home row and does exactly to 100% what you expect it to do. Every function outcome and every cursor position after a motion becomes predictable, and if you get better/faster on the way, vim becomes better/faster as well. I am discovering new things or different approaches to existing techniques every day and love every bit of it.

At my job, I spend the majority of my time thinking, browsing code, more thinking and a lot of reading. Once I know what I want to change, no matter where it is, I can jump with minimum keystrokes to the exact spot and do what I wanted to do.

If you want to learn vim, here is what I did: I installed Vintageous in SublimeText and only used hjkl for navigation while still using sublime functionality for everything else. Then step by step adapted motions, text objects and Ex. Once I felt comfortable enough, I gave real vim a try. On the way somewhere I also stole a entire vimrc from someone popular on github and started with that as my base.

The only problem in my opinion is that once you adapted to using vim, it is hard to go to any other editor that does not have vim keybindings/support/motions.

Emacs I think is worth it as well. Almost all terminals and editors come with built-in emacs keybindings for basic navigation and actions: Kill a word, jump to the beginning of the line, jump to the end of the line, go back a word and so on.

[0]: https://github.com/dvcrn/dotfiles/tree/master/vim

Another suggestion: Start vanilla, and slowly add in new commands/customizations slowly. For vim, for the first day, just stay in Insert mode, and move around with the arrow keys. The rest of the week, just add in Command mode, and use hjkl to move around. Next week, add in something else.

Once you're all trained up though, I think you'll really be happy you spent the time.

I learned emacs by using it as my note-taking editor, not for code at first. I'd have a cheatsheet open and all I needed were the basic navigation commands. Once I was comfortable I started coding in it.

The biggest benefit to emacs is the Mac UI and bash both share the same navigation keystrokes. My hand almost never needs to move over to the arrow/paging keys anymore.

Over time I've changed a lot of things to be closer to defaults. But I've also kept some of my customizations (I still use cua-mode, for example).

One downside to this approach is that you may miss out on useful parts of Emacs because your customizations cover them up or conflict with them. But on the whole it has worked very well for me.

vi / vim / emacs can be useful in certain situations (Unix / Cygwin command lines, low level embedded systems that don't have a desktop, etc), but for most code, the modern IDE GUIs blow them away. Code navigation / inspection / contextual browsing is much, much better, easier, and far more productive using Eclipse, CLion, Visual Studio, etc.

http://yehudakatz.com/2010/07/29/everyone-who-tried-to-convi...

[1]: https://www.donationcoder.com/forum/index.php?topic=37747

I initially used Visual Studio (around 2012) and really loved the power it gave me. I never felt slow or inefficient until I saw a screencast about Apache config that used vim and I was amazed to see how the person could simply jump to places he wanted. So I set out to try vim. I switched it for all my hobby work but it didn't catch on. So I went back to Visual Studio and in 2014 I thought I should give it another go. This time I started by installing the VsVim extension for Visual Studio.

This is how I got good with Vim: - In the beginning (I think 2 weeks) I only focused on using the motions (word, next character, paragraph, blocks and regex motion), common commands like d, c and R. If it helps I saw a screencast (one of the Vim London meetup videos) which broke down Vim into a grammar to be thought of as "operator + count + motion". I also slowed the key repeat rate to make sure I don't hold arrow keys to move. DISABLE ARROW KEYS IN VSVIMRC.

- After around 2 weeks I got comfortable with that and switched to pure Vim whenever I could. You can set up an external program to call up on the current file in Visual Studio. I also learned to touch type in the next 2 weeks so that I could reap more benefits.

- After a week of moving to Vim, I started writing my vimrc with things like colorcolumn, autoindent and other simple stuff. I also installed relevant text object plugins [1]. I installed some language specific plugins and started reading the :help pages. :helpgrep is very handy. At this time I think I felt I was back to my old productivity level if not above it. It took around 3 weeks I think.

- I then proceeded to learn about jumplist, named registers, location list, differences between buffers, windows, splits and tabs and how they are INTENDED to be used. It took me around one week.

- At that point I simply started looking at some Vim screencasts [3], [4], [5], [6], [7], [8] and [9].

CONCLUSION:

I am more productive in Vim when writing anything other than C#, F# or Java. Visual Studio excels in that department. I debug NodeJS in VSCode. For all other things I use Vim and am noticeably faster now compared to other editors. Although yes, I really miss Visual Studio a lot when using Vim. But thankfully Visual Studio has the great VsVim plugin.

[1]: https://github.com/kana/vim-textobj-user/wiki

[2]: My .vimrc https://github.com/hashhar/dotfiles/blob/master/neovim/.conf...

[3]: https://vimeo.com/vimlondon/videos

[4]: https://www.youtube.com/watch?v=xZTkrB_tEoY

[5]: https://www.youtube.com/user/ThoughtbotVideo/search?query=vi...

[6]: http://derekwyatt.org/vim/tutorials/index.html

[7]: http://vimcasts.org/

[8]: http://tilvim.com/

[9]: https://sanctum.geek.nz/arabesque/vim-anti-patterns/

It's like anything in life, you just have to make yourself do it. There's no substitute for putting in the work and time. Sure, it's painful for the first few months, but I believe it pays off in the end.

I think the biggest thing is this: you say you try every few years to learn these editors. Don't quit next time.

I switch between IntelliJ and Emacs all day, and all I had to do to become comfortable is choose the Emacs keyboard preset in the IntelliJ preferences. The same is true for Eclipse and Visual Studio.

The Emacs paradigm is a lot more similar to contemporary IDEs than the Vim paradigm, and that makes it a lot easier to switch back and forth.

While a better Vim is a nice goal, I don't see how it will bridge the gap between Vim and newer editors/IDEs unless it includes some fairly fundamental changes to the Vim paradigm. But then it wouldn't be a better Vim -- it would be something different enough that Vim users probably wouldn't like it. I suspect that Vim and modern editors/IDEs are doomed to remain divergent forever.

Like: I've used Emacs extensively in the past, and certainly _could_ switch to evil if need be, but a few days of recent effort showed me that the switching costs are higher than I'm willing to pay right now, and it's not clear I'd be any better off in the end.

Whatever the infelicities of vim's implementation (there are certainly plenty), I think there's a tendency to underestimate the expressive nuance and (for lack of better words) complex texture of the interface.

It's simply not true that the vim modes outside of vim are critically lacking.

In fact almost all of them support text objects and the other key parts of the vim editing experience that we are talking about here and they do it well.

Some things like macros or perfect register support are not there (evil is pretty great though) but they generally have useful analogs.

This is across multiple IDE emulations that I've used.

What you said might have been true 6-7 years ago but is not true now.

This is so important. It's the reason I've stuck by Quicksilver all these years, and avoided Spotlight and whatever Google's search bar thingy is called.

I've never been interested in vi because the effort to reward ratio doesn't seem favourable, but I think I'll give Kakoune a try.

("Probably": last I tried using Alfred a few years ago, I think there was something I relied on QS to do that Alfred couldn't. I can't remember what it was, maybe Alfred does it now - but again, why bother? QS still does everything I want it to do.)

Also QS's interface looks cooler than Alfred's to me. Aesthetics matter.

Even back when QS was under active development by the original author, it was still pretty buggy. I actually had a separate keyboard shortcuts app running in the background with a single shortcut which would relaunch QS for those times when QS decided to crash.

I am curious what you relied on QS for that Alfred can't do. Everything I remember doing with QS is doable with Alfred.

Alfred didn't have that basic structure when I tried it. I'm sure it's quite powerful, probably more so than QS given the latter's long stagnation. But I never bothered to figure out how to use Alfred effectively because QS is so easy and works great. There were a couple of bugs that were annoying for a while, but they've been fixed.

Kakoune doesn't mention the "indirect object" part of the grammar, but apparently it'll prompt for more information when needed, so it's pretty close.

That said I suspect most people would be better off learning a good IDE properly, including but not limited to:

* effective navigation and selection using modifier keys and search

* built in refactoring

* project wide as well as single file search/replace, -and this includes regex search AND replace.

This should be quite doable in less than a week compared to a few months to get equally effective in vim.

Edit: let me add that parts of this looks like a huge improvement over vim.

To be clear, do you think a "good IDE" is inherently better than Vim/Kako for most people?

Personally i don't see a difference in a GUI based editor and a text based editor. In fact, i quite prefer text based, because it forces an editor to treat the keyboard as a first class citizen - GUI IDEs can get lazy and revert to mouse whenever they please.

I can see the argument that Vim might not be inherently as good as a "good" GUI editor, but i don't think that is a negative towards the potential of text based editors. It just means that we need new editors to focus on the UX, imo.

With that said, i'll be quite glad that we're moving towards standardizing (of sorts) a code editor protocol so that new editors don't suffer from lack of tooling. It will be great to see a single set of tooling (formatting, linting, imports, syntax checking, etc) plug into any new editor that might pop up.

Switching editors has enough friction, tooling shouldn't be one.

Right now, for most people: very much yes.

Personally i don't see a difference in a GUI based editor and a text based editor. In fact, i quite prefer text based, because it forces an editor to treat the keyboard as a first class citizen - GUI IDEs can get lazy and revert to mouse whenever they please.

Fair point. However: Between the default keybindings of Netbeans on Windows or Linux and the simplicity of customising it to my hearts content I haven't found any reason to abandon it.

I can see the argument that Vim might not be inherently as good as a "good" GUI editor, but i don't think that is a negative towards the potential of text based editors. It just means that we need new editors to focus on the UX, imo.

Here is where I'll argue that the main advantage of the big IDEs are that they have focused on UX for years.

Yea, i definitely agree there. It's also that GUI IDEs tend to cater towards.. well, a different crowd. What that means in real world terms in often a product with rough edges, confusing patterns, and a horribly steep learning curve.

I enjoy seeing products and languages (programming) focus on learning as core feature of the product. It really is inherently important to a projects success.

It's a lost cause in this industry.

You say that, but somehow I still find the UX of every IDE I've tried to be lacking. I much prefer the UX of Emacs.

You have to realize that psychologically: you like things you're familiar with, and dislike things you're unfamiliar with. That's how top-40 radio works. That's why everybody bitches over every new software update, even when the new version is provably better.

So of course you like the thing you spent years with over the thing you tried to learn for a week and a half then gave up on because Emacs is better. That has nothing to do with UX.

In effect, a modern IDE is "programming ability" multiplier. It helps me code smarter and faster. That plus understanding what's going on behind the scenes is a powerful combination.

The difference is that IDE-like features Vim are simply tuned for C (add Lisp for Emacs) instead of Java; plugins give them support for other languages. Anyone who has tried to write something other than Java in Eclipse can attest to how much plugin creep starts to enter the fray.

IDE's and text editors overlap in their uses, but they are not the same. Sometimes you really do just have a text editing task, and none of the IDE functionality will help with it. Also, the ways in which IDE's are extensible is lacking compared to something like Emacs. Yes, they come with a bunch of built-in useful stuff, but sometimes you want to add a keybinding to do some editing task you do a lot in a particular project or company, even if it's not useful in a more general-purpose setting.

Don't know what IDE you used but Netbeans is very customisable and extensible.

I think this is true for IntelliJ and eclipse as well and it would surprise me if it wasn't for Visual Studio.

(In fact I think I have seen vim modes for all of these and even embedded vim in eclipse.)

In Emacs, adding a simple extension is simply a matter of adding a function to your .emacs file. So adding useful functionality is very low friction, low enough that you can afford to do it when it wouldn't be worth the effort in an IDE.

With that said, it's purely speculative on my part, i clearly don't know - Kakoune is new to me.

I doubt Visual Studio will be much harder.

Jetbrains covers Ruby, Python, JS, C and more and it would surprise me bigtime if those language specific versions aren't quite similar to the plain Java version as well.

I always use cl.exe from the command line with Makefiles.

Visual Studio can be operated pretty much entirely from the keyboard. The default shortcuts are fairly sensible, and you can always add more from the options.

There is one major omission: changing build configuration or build target. (You can give the configuration manager a keyboard shortcut, and do it that way, but it's a bit unwieldy.) So I keep the relevant widget in the toolbar and use the mouse to do it. And there are a few things I haven't bothered to assign keyboard shortcuts to, on account of how rarely I use them.

But in general, I use the keyboard to perform actions, and it doesn't feel like I use the mouse any more than I do with emacs (which I use without scrollbar, toolbar, or menu bar).

I do use the mouse a lot for moving the cursor and selecting text in both cases. (Visual Studio is actually slightly better for this, because you can Ctrl+drag to get word selection.)

Over the years I've observed that VS criticism is downvoted quite rigorously here. This is in stark contrast to the overall sentiment on the Internet, so I suspect corporate downvoting here.

The moderators should take a look at it.

Because you have to learn more commands/shortcuts than in Vim? ;)

A few hints to get reasonably good, fast:

Use ctrl+arrowleft/arrowright to jump words at a time.

Use shift to select as you move.

This works together so ctrl + shift + arrowright means select to the next word boundary.

At keast in some IDEs this will also stop at word boundaries inside a variable or function name but this should be configurable. I prefer it this way though.

Next: in the menus you'll often see a hint that tells you a direct shortkey for that menu option. This holds true for both window menus on the top as well as in the right click context menu.

Use w, W to jump words at a time.

Use v before moving to select as you move.

This works together, so vw will select to the next word boundary.

Press i to insert text, escape to stop inserting text.

Next: in the :help files, you will find a hint that tells you a direct shortcut for that command (like :help quit, or :help write, or just plain :help).

I guess my point is just that it seems to me a lot of people (not necessarily you guys) use vim as some kind of cargo cult.

If you aren't willing to learn more than the Vim shortcuts, it's unfair to criticize Visual Studio or any other product. You are the problem.

With Visual Studio, the documentation is horrible, you always encounter stale links to unorganized and regularly changing microsoft.com websites.

Relatively basic things are left unexplained and documentation is outsourced to Stackoverflow:

1) How do I restore the output window I clicked it away in order to make the editor usable in the first place?

2) What the heck is a "project" and why do I need one?

3) Why do I need so many frigging clicks to get to the debugger (the debugger itself is nice though I have to admit)?

The list goes on an on. All these things are far simpler with vim and gdb: Need to debug x87 fpu registers? One simple google search and you have an instructive plaintext website that tells you everything and off you go.

There are many ways, it comes down to personal preference. For example, would you prefer restoring the Output window using a keyboard or a mouse?

>"2) What the heck is a "project" and why do I need one?"

The same reason you probably use a makefile when working with Vim, to manage your dependencies and build configurations.

>"3) Why do I need so many frigging clicks to get to the debugger (the debugger itself is nice though I have to admit)?"

I don't know what you're talking about here, the debugger is accessible with hardly any effort at all. How many clicks are you using to bring it up?

>"The list goes on an on. All these things are far simpler with vim and gdb: Need to debug x87 fpu registers? One simple google search and you have an instructive plaintext website that tells you everything and off you go."

Depends on your use cases. I've personally never found MSDN documentation lacking, plus it's ridiculously easy to use. For example, when coding in C#, highlight a language keyword and press F1, you'll be brought to online documentation about that language feature.

> Another often overlooked property of using a text editing language is that it’s fun.

Some other things that I like about it that are not mentioned:

The author is responsive to feature requests and bugs on github.

The codebase is very well-made, if you have any interest in C++ I recommend taking a look at it.

> " Due to Kakoune relying heavily on being in a Unix-like environment, no native Windows version is planned."

Deal breaker right there.

If I am going to go to the effort of learning a new editor, it better run on all reasonable platforms - like Vim does.

For example, this means that plugins trying to extend grammar analysis, will primarily try to rely on their already existing parsers and tools via the command line. This means a streamlined process to create plugins / extensions to the editor, and the function of the editor is well defined.

Plus, with the unix subsystem (minus bugs) you can still run this in Windows. That still amazes me.

With that said, Windows is working on that embedded native linux thing, so i imagine it will work there.

This smells like confirmation bias to me.

This is a straw man argument.

I already use perfectly good multi platform editors like Sublime and Vim and I have Emacs as an option, although I have not used it much. There is a significant investment in time required to use a modal editor like Vim (and apparently Kakoune) at even close to a decent level. I simply prefer to not have to change editors every time I change platform, since an editor is a tool I use a lot and I have the option to not be restricted by platform limited editors.

Even some kind of auto model visualizer that helps every so often like a replacement for the ignoble package mmanager side panel view.

We're still so stuck on text editing.

I mean, the features you talk about are great-- but right now I can't even embed a little vector graphic explaining a function's flow in my source file. Every time I've suggested using a file format that allows things like fonts, styles, embedded images, to write my code, the reaction is always an insanely irrational knee-jerk against it. (Seriously, try it out with your programmer colleagues.)

(And to prod the bear a bit, a large part of the problem is the developers who insist in working in tools like the ones we're discussing here, designed in the '70s and using absolutely no technology that was invented after 1985 or so. Ludicrous. Imagine if any other industry worked that way!)

Then a couple days later, you found out they spent like an hour making ASCII art of some diagram because they couldn't just paste the actual diagram into the code. Sigh. Reason #3136269 I don't get along with other programmers.

I mean you're talking about advanced AI code that looks up Google links to explain code constructs, meanwhile 95% of the industry is using a code editor that doesn't even allow you to embed a link in a code file. (If you're lucky, it'll make an obvious URL clickable, that's about the best you get.)

Good argument?

What you're talking about is turning source code into a binary object. That's fine, if you use an editor that supports it, but you shun all other editors when you do that. There is a middleground that doesn't involve making your source code into rich text, imo.

As for "shunning other editors", well, frankly, why are we as an industry bending over backwards to support people using editors from the 1970s? Do you think Ford still builds cars with imperial measurements just so Old Bob the mechanic can keep using the tools he bought when he went into the field in 1968? No of course not, that's stupid. But that's exactly what our industry is doing.

RE editing text: whatever code object model one can imagine, it generally always serializes to text. I for one don't see the benefit of editing an abstract model in place of text. An example I liked was Fortress [1]. Fortress was a language that attempted to let users write code in mathematical notation using a special latex editor (iirc). It was found to be not a huge win, and they reverted to 'normal' syntax. This was one of Guy Steeles projects at sun.

So having said that, there are languages where editing the model is editing text: Lisp and Scheme.

[1] https://en.wikipedia.org/wiki/Fortress_(programming_language...

Still a shame that it is entirely console-based. It's 2016 people! We've had GUIs for literally decades.

Neovim separated the client and server parts, and there are a host of clients (QT, HTML/Atom, etc) including the canonical one, from the docs:

    When compiled with the |+clientserver| option, Vim can act as a command
    server.  It accepts messages from a client and executes them.  At the same
    time, Vim can function as a client and send commands to a Vim server.

Maybe Kakoune does the same, I haven't checked. I also second the first child's note that being console based is a feature.

fta:

>The first thing to realize is that non-modal text editors are extremely biased towards insertion. They make insertion easy (by making the default behaviour of most keys to insert a character into the buffer) at the expense of making most other operations suboptimal, by requiring hard to reach keys or modifiers (or, even worse, moving your hand all the way to your mouse).

i disagree whole heartedly that reaching a modifier key is some great expense. I can do many things very quickly in sublime and have never felt that there was any time loss hitting a modifier key. compared to the expense of:

1) occasionally entering several commands by accident when in the wrong mode and having to correct it

2) lack of ease of use both for initial learning and for other coders who might have to type something on your comp when pairing and they dont use your exact modal editor

3) lack of transitionable skills to other editors, difficult discoverability, and many other side effects of modal systems

i respect the choice of others to use modal editors but it is absolutely not some cut and dry thing as the author presents it.

i can do things in sublime at probably 90% of the speed of someone in vim and perform many or all of the same operations including some you cant do in vim etc thanks to plugins.

aside from all that, reading, writing, and navigating code are not my bottlenecks for productivity anyway.

Maybe for beginners, but this almost never happens after a while, and hitting undo takes 0 time.

> 2) lack of ease of use both for initial learning and for other coders who might have to type something on your comp when pairing and they dont use your exact modal editor

You have a point for learners, but I'm not going to pick my tools based on what other people need, I'm going to pick them based what I need.

> 3) lack of transitionable skills to other editors, difficult discoverability, and many other side effects of modal systems

Don't see this at all. Vim-like editors have a pretty standard set of objects/verbs, many programs use vim style keys (less for example). How are you going to transition say, IDEA, or RubyMine, or Emacs specific key shortcuts or plugins?

Update: 2 more

> I disagree that reaching for modifiers is some great expense

It is when you are using "commands" at the rate an experienced vim user is. Excluding single char/line navigation spam, I use about 20-70 a minute if I have a good conception of the change I want to make.

> i can do things in sublime at probably 90% of the speed of someone in vim and perform many or all of the same operations including some you cant do in vim etc thanks to plugins.

A) I doubt that. I've seen people rip through stuff in ways that cannot be done without modal editing. For more concrete examples, look at some vimgolf problems and see how sublime solutions compare. keystrokes are a good measurement IMO because it's independent of user typing speed. Not that the average vim user edits like that, but just as an example of what's possible.

B) Saying "with plugins" is a pretty arbitrary measurement, unless you're trying to claim there are plugins in sublime which you can't implement in vim. Do you have a specific example?

  > We've had GUIs for literally decades.

But you do switch how your mouth is working when switching between eating and drinking. In one, you masticate and move food around your mouth before swallowing once (maybe twice), whereas the other involves directing fluids back to your throat which acts in a near-continuous swallowing action.

> You have to remember so many key combinations and commands

They become muscle memory after an admittedly non-trivial amount of use. Yes, it is an investment in your future usage of that tool.

And to be fair, you had to memorize C-x, C-c, and C-v at one point too.

You might be surprised. Maybe not quite the level of a true "reflex", but it can get close. I find I not infrequently get weird compile/test/spellcheck errors when I'm not using vim and go back to find a string of vi keystrokes in the middle of my document that I typed without consciously realizing.

Jokes aside, do you understand the architecture of a system better from a diagram than from a 2 page description?

Not being destructive of user input, for starters.

Anyways, I don't think such behavior is inherent to "the console", only Linux's particular implementation (i.e. it's tty's fault) which admittedly is pretty outdated and relies a bit too much on control characters.

IMHO the original question still stands:

> What would a GUI bring to this that isn't possible in the console?

In my experience text mode brings a lot that GUIs don't, and not the other way around.

Plus it's easier to make a GUI wrapper for a console program than a console wrapper for a GUI program.

I also absolutely agree that this is the correct way for an editor to be implemented.

Visual editors assign various non-editing tasks to command sequences as well. Pycharm moves the cursor around parenthesis with C-m for example, Cmd-M minimizes windows, and Cmd-I does formatting.

No applications running in the terminal will be able to tell the difference between these two different key presses.

Granted, it won't support using variable-width fonts as-is; but that's never been a problem for me.

I took a stab at it, and while it still needs half of the features to be on par with the terminal UI, it gives an idea of how difficult it would be (it isn't): https://github.com/doppioandante/kakoune-qml

I love/like vi[m], I love/like emacs... I ... never mind lol

The new editing language does look great, and I like the idea of the piped filters... but I can't get over the name :-/

I dabble in vim and it's my editor for when I quickly want to change stuff whilst in a terminal, but not enough to be "proficient" in it. As others have noted, I feel there could be a massive gain in editing if I were to get more acquainted with the many vi commands, but the initial productivity penalty has stopped me more than once from making it my default editor. Kakoune's mental model of commands seems friendlier, so maybe it will stick :)

However, «vi» means visual, while it is the least visual editor among popular editors, so I expect by analogy that kak will be very good editor. Keep fingers crossed. :-)

https://github.com/mawww/kakoune/blob/master/doc/manpages/fa...

Definitely should include a link, though.

* No NodeJS/NPM * No Electron * No multi-threading

> "No threading: multithreading is a hard problem, and is not well suited to a text editor:

Either we want a direct result, and we need to be synchronous with the user, so getting a 4x speed up is meaningless, we need to have an algorithm which appears instantaneous the user.

Or we want an asynchronous result, and then the processing is best left to a helper command which can be reused with other Unix tools."

I agree with them. Multithreading today in all situations is like Fuzzy logic of yesteryears. It is suppose to make everything better.

Does it have a different scripting language, or is it still VimL? What kind of plugin support does it have?

Is it embeddable? Does it have a messaging API like Neovim?

How well does it handle long text lines and long documents?

No scripting language, most of the heavy lifting done in plugin is through shell calls (asynchronously or not). Example here [1]. I personally think that it's kinda hard to grok to be honest.

Thanks to the client server architecture, it is possible to make an external UI[2].

There is no line wrapping currently. Don't know about long documents, but the editor in general is very efficient.

[1] https://github.com/mawww/kakoune/blob/master/rc/core/grep.ka...

[2] https://github.com/mawww/kakoune/blob/master/doc/json_ui.asc...

This is an important note to me, because i imagine i'll have to implement my own tools for common language tasks like Gofmt and Goimport.

Honestly, it would be cool if i could write plugins in any language i want, ie if it fully uses a backend editor server API.