The last one is compelling, but the new "editing language" and paradigm that's been put together is _really_ compelling. Being able to see what a "sentence" is going to do as you're typing it is a huge improvement on vim. I _love_ vim, but executing complex commands is like shouting into a dark tunnel and hoping the person on the other end understands what you were trying to say.

That's why I tend to use visual mode. It sounds like Kakoune is basically visual mode by default, which is cool but not that different.

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

If you just replace 'd' with 'y', though, the example is a good one: hitting period would just yank the same thing again.

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.

If you aren't sure where you'll end up with, do, in this case

   mmffffy`m

Why would this be better? Because it works in macros too. In vim, you can record it as you go. In vi(nvi), I write it somewhere in the file, basically after I did it once, I would do

   Ommffffy`m^[0"wDdd

and use

   @W

later.

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

Seriously? What is the advantage of using your cognitive capabilities to write Ommffffy`m^[0"wDdd rather than use a sensible IDE with common refactoring capabilities that are also context aware and integrated with the language you are using?

In vim the only part you need is mmffffy`m.

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.

SQL is just inherently repetitive. What I would do with macros is start with a simple list of column names and turn it into a statement updating them all, or a join, or whatever I needed. Eg. a macro could turn "FirstName" into "a.FirstName = b.FirstName", and then work just as well on "LastName".

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.

Sure, I thought of that. Then instead of a variable named "salary" you've obfuscated your code by calling it a[4].

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?

Or as I suggested earlier you just use objects instead of random variables.

    employee = new Employee();

And you have all the fields reinitialized to the correct default value (that can be different from zero) and much better naming because now you can tell the difference between employee.Username and user.Username

Sure, and I do that when I can (e.g. not when I'm writing SQL), but the point of my quick examples isn't to show off my software engineering, but to illustrate what vim can do in the simplest way I can think of.

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

Have you seriously never ran into a situation where your IDE does almost what you want, but you still have to do some bit of it manually just because IDE can't handle this specific thing or format or whatever? If so you are either spending way more time thinking about your architecture and code before writing anything than most people or your IDE is fucking amazing.

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.

> If I want some repetitive behaviour (create new class, generate code) I'll use the [...] behaviour customised to my needs

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.

A class is certainly not a function, I was speaking about generating valid code in response to a sequence of key strokes / mouse events. If I am building a new module I start with a concrete class and just right click -> extract interface -> select appropriates / all public members and I have a new file with the interface definition. If I am modifying the class I pull the members up to change it. If I just created a new class from scratch I make it inherit the interface, ALT+ENTER and all methods are generated. with the uncountable templates you can do pretty much whatever you want, from generating constructors, creating properties and who knows what else. I have seen people use it live in conferences to generate part of their demo code. All of this is safe and the result compiles correctly apart from the uncommon cases where you need to explicitly ask to make it non compilable.

If it goes wrong, just hit u to undo.

nvi is not Vi; it's a fork of Elvis: another Vi clone, like Vim.

Vim is older than Elvis, by years.

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

Wikipedia has Elvis predating Vim by nearly 2 years (January 1990 vs. November 1991).

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/ ;)

I never thought of it this way, but visual mode essentially does switch vim from verb-object to object-verb.

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)

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.

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.

No.

   "1p.

You got me. I don't know how to parse that ("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.

You can be sure that the Kakoune authors are familiar with vi(m).

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

>I just wish you guys can learn more of vi, so you can truly deliver something better. So far, these surface scratching alterations only build on irritations of those vi first-timers

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

You know there's a setting to display the current command in the status line right?

There's a difference in knowing what you've typed and what that means. Displaying the current chord protects against typos and losing track, but doesn't help you understand what your command is doing.

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.

Unless I misunderstood that won't show the result of the command.

This is also quite an important difference:

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

I'm thinking about whether this is a good idea. He gets vi/Vim's model slightly wrong by saying it's "verb then object". While that is true for some things (i.e. text objects, like "ciw" for "change inner word"), it's not true in general. The general rule is "verb then motion". In "dw" ("delete word"), the "w" doesn't represent an object, it represents a motion (going one word forward). It's the same motion that I can use for any command, mapping, or indeed for just moving through text.

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.

>How would that work if the motion comes first? Would I go "wwwwd"? Would that delete one word, or four?

'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

Can you add counts to motions/objects? I.e. does "3w" select three words you can act on, or do you have to go "wWW"?

3w works

as well as 3W, for a different purpose

w irritates me, because it always traverses a bunch of miscellaneous symbols, and my brain can't parse fast enough to easily tell in advance how many times I'll have to press w in order to get where I want. Extremely minor, but extremely niggly annoyance. I've found myself using https://github.com/justinmk/vim-sneak more and more often.

You might also like quick-scope:

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

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

I often use visual selection mode in vim so that I can see what I'm about to operate on. For instance, if I want to change text between the cursor and the next match of a regex, I want to see the selection before I change it. So instead of c/re[enter], I type v/re[enter]c. It's one extra character, but it saves me a lot of headaches. This is the first I've heard of Kakoune, but I'm definitely intrigued.

Probably too late for anybody to see this comment, but I'd just like to drop back in and say I've tried it and it's amazing. I really did not expect that another text editor would be able to improve on Vim on basically all fronts, but kak has done it.

In this age we need to think about things like voice control and 3D manipulation of data-structures and a dynamic view of the code.

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.

Yes, but. Keep ripeness in mind. It's very easy to spend effort in this area "too soon". So shape projects with care.

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.

Very well put. I have to agree that these technologies are still blooming and there are uncertainties--especially in my mind with cost associated with buying devices. Hololense for example with a $3000.00 USD developer edition isn't exactly accessible to the general community! The next 10 years however will probably be pretty exciting in the AR/VR space.

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!

You might enjoy http://www.iquilezles.org/live/ where he live codes some ray-marching using some kind of opengl editor. It's not quite what you're talking about, since it's just running the opengl code, but you could imagine it going through some kind of compiler/visualizer pipeline like you're thinking about.

There is some movement in this direction

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

Well consider if you use both dictation and typing simultaneously. Vi and kakoune are ergonomic because it requires minimum changes to hand positions. But if you added voice dictation like "toggle tab 2" or "toggle terminal" or "go next brace" etc, all while STILL typing my guess is efficiency would go up physical fatigue would go down.

Folks have created Dragon-based voiced-sound vocabulary for editor control. Voice strain is an issue, but you can load share with typing.

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.

Sounds interesting. When are you going to start on it?