Kakoune is an interesting concept because most post-vi editors have abandoned modality, and Kakoune embraces it wholeheartedly in an attempt to capture the essence of what makes vi powerful and attractive for a certain type of user, but trying to ditch some of the historical ed/ex syntax and thought patterns that make vi weirdly inconsistent. I don't think kakoune is quite there -- I think the multi-selection gimmick is not strong enough to be worth being first-class (especially the way that search-and-replace works), too many common operations are chorded, and there's no selection "mode" -- you have to remember to keep pressing 'J' as long as you want to grow the selection; one 'j' and you're lost.
In programming languages I think we're seeing this happening also; C has remained a prominent language despite its age and the number of C-killers that have emerged over the years, and now we're seeing a resurgence of projects that are really trying to preserve something at the heart of C that has made it attractive for so long, but that even the most jaded systems programmer can see are not ideal, like the fact that types precede names in variable declarations, or the lack of a keyword for function or variable declaration that make it hard to grep, or the superfluous parens in ifs and fors that are obviated by mandatory blocks, or the default pass-through behavior in switch statements. Previous attempts, like C++ and D, have diverged too much from the simplicity of "I can imagine what the assembly code for this function will look like based on the compiler in my head", Rust has some attraction, but nim and zig and Jai and v are all emerging to nuzzle into that niche by restricting their feature set.
Honestly, I find it shocking anybody can hold this opinion.
I hate that every single new language insists on types being on the right. I searched for a reason why this is, and typically the results are along the lines of type inference being easier to implement. I'd prefer to take no inference at all and have my types on the left, where they belong. I'm totally serious.
Types on the right are a readability disaster.
I've been envisioning a future programming environment that automatically aids in code readability by hiding unnecessary information when you're not using it. Manual code folding was sort of a first step, but this environment would take it further by hiding things like types until you need them. So something like
proc eval(c: Criterion, token: Token): bool =
let tokenCrit = (token.identifier, token.token)
return tokenCrit == c
proc eval(c, token) =
let tokenCrit = (token.identifier, token.token)
return tokenCrit == c
proc eval(c, token) =
return tokenCrit == c
This is just a rough idea and I'm not sure how well it works in reality. But when code starts looking like `proc add*[T](root: var BinaryTree[T], n: var seq[BinaryTree[T]]) =` it starts to lose its at-a-glance readability.
Seems to me there is a desire for editors that allow a user to transform code, whether it be annotations or raster graphics as Bernhardt puts it. The closest I know of is org mode, and how it works on a plaintext interface but has no qualms about displaying it in wildly different ways than an org file might look opened up in vim, though it still does maintain readablity. I think this is the way to go and I've been playing around with a personal workflow on top of org mode lately. What do you think?
The other problem with the type-on-the-left is that variable declarations are hard to find without tooling designed for that purpose. Being able to search for "var x" is a nice feature that makes it easy to separate out the declarations from the usage.
I agree that type inference and optional types is something of an anti-feature from my perspective as well; even more frustrating is languages that treat a type declaration as a type assertion rather than a declaration, which serves to divorce ideas about physical storage from the code; abstract types like "bool", though, have already crept into C to make the type model a little more complicated than it has to be. Types in C used to be declarations of storage class as well; now I know that a bool in a struct will take up a byte, but that byte and bool are not really compatible types makes it a little harder to reason about, even if that does give better hinting to the compiler.
If type expressions were readily recognizable from other expressions (for example, you can force types to be CamelCased and assigned different lexical classes like ML) then it'd be probably a pure personal taste. But a C-style definition? Big no-no.
isValidPass :: Text -- ^ cleartext password
-> SaltedPass -- ^ salted password
isValidPass ct salted =
PS.verifyPassword (encodeUtf8 ct) (encodeUtf8 salted) || isValidPass' ct salted
That's a very, very simple one. Take look at this other type signature:
widgetToPageContent :: (Eq (Route site), Yesod site)
=> WidgetT site IO ()
-> HandlerT site IO (PageContent (Route site))
:: (Eq a, RenderMessage site FormMessage)
=> (Text -> Text -> [(Text, Text)] -> WidgetT site IO () -> WidgetT site IO ())
-> (Text -> Text -> Bool -> WidgetT site IO ())
-> (Text -> Text -> [(Text, Text)] -> Text -> Bool -> Text -> WidgetT site IO ())
-> HandlerT site IO (OptionList a)
-> Field (HandlerT site IO) a
I know these types might look needlessly complicated to someone that doesn't know how to read them, but when you learn to understand them, they are a blessing. Most of the time, a type will tell you everything you need to know about a function or other value. They're often better than the documentation to know what they do.
Another advantage is that they simplify looking for the type signature of a function. You just need to `grep '^identifier'` instead of what you would do for C++, for example, `grep 'identifier\('` and manually filter out the calls.
Also, having it on the right permits one to comment on different parts of it, just like one would do with non-type code.
I don't see the sense in ever having it on the left (where's the benefit? just having it look like C?), but I guess it's not unacceptably bad on unexpressive type systems where the type is hardly more than a type identifier.
And as for greppability, it has become very common now to use keywords, which were very common once upon a time but went out of favor with Algol, so that you get declarations like "fn isValidPass(...)" to make grepping even easier.
And easy grepping also means easy parsing, which works both for machines and for humans when you're trying to digest unfamiliar code.
I'm not trying to sell Haskell to C developers, though, I was just replying to the GP's disbelief at a syntax preference for having types on the right. Also, I don't think the ability you mention has anything to do with the choice of syntax of having types on the left or the right.
I do very much wonder if there are any benefits, at all, of having the types on the left.
EDIT: On re-reading my above comment, I guess I was selling it a little, but I only meant to justify having complex looking types. :P
So the declaration on the left [ed: Was right] makes a certain amount of sense - you’re declaring an int, so that’s what you lead with. When you declare a “string” you have to think about how the string is stored; and that implementation detail bleeds into the syntax.
A C has matured the notion of incompatible types has seeped into the language to the point where now it becomes a little annoying that I can just go ahead and pass an int into a function that expects a typedef’d “type”; libraries often wrap them in very lightweight structs just to get an additional bit of typechecking. The expectations for what kind of errors the compiler can catch have grown over time but the language has only made small concessions.
I'm sorry, but that doesn't make sense to me. You say it as if it's the only sensible way to design a declaration syntax, but Haskell (and other languages) did it the other way just fine. I don't see how the differences in semantics between the 2 type systems give rise to a benefit in having the type expressed on the left.
If the design came to be decided like that, it seems it's simply not something that was put much thought over. That's fine too, since the limitations of the type system do not give rise to cases where this syntax choice becomes too big of an inconvenience.
Still, no benefits as far as I can see. Maybe it simply appealed to the designer's intuition more. Choosing because of that indicates that the choice was pretty arbitrary, though.
> You say it as if it's the only sensible way to design a declaration syntax
I don't say that -- in fact, I'm replying to my own post saying that the declaration on the left was a mistake. My only point is that it is a design decision that has some historical grounding.
This is an unfair comparison, in C, only the return type goes before the function name, the argument types go inside the parens.
Thanks for pointing out v, which I didn't know about!
Agreed. I also don't like that this system requires you to have what are essentially duplicate keybindings with the only difference being that one does the motion while starting a new selection, and the other does the motion but keeps (and extends) current selection. It guess it's supposed to be ergonomic, but I think it's too wasteful and in wasting so many possible keybindings, we're trading ergonomy away by not being able to bind more powerful functions to all these spent keys.
I'm not sure what the solution should be. I like what Kakoune is trying to do, but I don't think they landed on the right idea.
I'm not sure I'd like having to toggle selection mode on or off. I think it'd be better to always be in the selection mode; then if you don't want all your recent navigation selected, you press a key to reset the selection. The obvious downside is that you'll end up having to reset the selection a lot. On the other hand, if it's only one easily accessible key, it might work well enough.
A slightly more advanced solution would be that you always have a selection formed automatically from the latest motion, plus a mark (perhaps any number of marks) that can be used when you need to combine multiple motions. Normally editing commands that take a selection would only operate on the most recent motion, but with a single prefix or postfix key could be extended to apply up to the mark.
Whatever it is, I think there's got to be a way to improve on vi without making as many tradeoffs as I think Kakoune did.
When you make a motion you have to decide which one of the endpoints is the current cursor, and that's where I feel like you run into trouble. "Grow the selection up by one line" is a hard notion to express when you started by selecting down. Vim has visual select mode, which has a line-based, character-based, and block-based mode. I'm not totally sure that we need them to be distinct.
The problem is that kakoune now has me vaguely dissatisfied with both vim and kakoune and I don't like it.
In the rare case case when I miss the mark, I wouldn't mind pressing an extra key to move the cursor to the other end of the selection and expand from there.
And yeah I feel that dissatisfaction too.
With the text below, your cursor is the pipe character. From the cursor position, in normal mode, press 'vjok'
Also my goodness having built-in multiple cursors is fantastic. Kakoune multiple cursors is much much better than the vim plugins for multiple cursors.
As other people have said though, there are some plugins that have yet to be ported to kakoune. iirc smooth scrolling (comfortable-motion) and vim-wiki to name the ones that come to my mind.
One funny anti-pattern I just noticed I have recently is when editing the last line I've written in notes I'll open a new line with O then immediately exit to normal mode, only to have the next thing I do be to hit i for insert.
I guess my long winded point is that it's easy to have anti-patterns sneak up on you and it's nice to see someone else's re-designed keybindings on a modal style interface to spur reflection on our own setups.
Also, I meant to say that the my replacements for 0, $, gg, and G are gh, gl, gk, gj. 'g' for 'go' and 'hjkl' for the standard up, down, left, or right.
Sadly, even though this looks amazing, I don't see myself using it until most of the plugins I use for Vim have been ported over. Does anyone here use Kakoune as their daily driver? Do you feel it's worth the switch from Vim?
I still use vi / vim for some of the usual suspects. I haven't bothered to change my $EDITOR, so I always default into vi unless I explicitly invoke kak. (Like right now, w3m invoked vi for me to write this comment.) And then there's visudo, which is far too much of a pain to set up for using kak. And kak doesn't to my knowledge have anything like vimdiff. Also, it doesn't work as well for what I call "interactive sed," where you do a global regex replacement. For ordinary source code editing though, I'm not going back. Selection-oriented editing with multiple cursors is just too much fun.
- Type `:%s/`
- Spend 30 seconds thinking up a regex which will hopefully match all the things I want to change, and none of the things I don't
- Write it out, hit Enter
- Run my tests, or run "git diff", or generally review the changes, and find a bunch of stuff is broken
- undo, restart from scratch
You can sometimes avoid screwing up the entire file with the "c" flag that asks for confirmation for each change, but it's too easy to get bored and distracted and type "y" too many times.
In Kakoune, a global regex replacement goes like:
- Type `%s`
- Spend five seconds thinking up a regex that approximately matches the things I want to change
- Interactively do any additional adjustments that are difficult to express in regex, like the `M` command that extends the selection to the next matching bracket
- Cycle through matches with `(` and `)`, checking to see if they're what I expected
- If not, I can remove individual selections with Alt-Space, or just hit %s and adjust my regex
- Type `c` and actually make the change
Because of the whole "multiple cursors" thing, I can get fast feedback on each part of the process, so I can get the result I want much more quickly.
- :set hlsearch
- Type `/`
- Hit Enter
- Cycle through matches with `n`/`N`, checking to see if they're what I expected
- If they're not, press `/` then <Up> and edit the regex
- When satisfied, type `:%s//`, enter the replacement you want to make, then `/g<Enter>` to apply the change everywhere
The "c" modifier makes you confirm each replacement, and you can y/n for each of them.
The only thing stopping me was my inability to configure it to use different indentation settings per file type.
I'll definitely try again at some point. I love Vim and have used it for nearly twenty years, but Kakoune's grammar just makes more sense in several ways.
Do you mind listing plugins you miss? That's probably depends on use-case but my impression is most of essential stuff is already available.
> [Tesler's] career forms a link from the pioneering work of Doug Engelbart, Stu Card and Tim Mott, to the emergence of a dominant design for the PC, as described by Bill Atkinson, Cordell Ratzlaff and Paul Bradley.
When he was at Apple, Larry Tesler had a license plate saying “NO MODES.”
That's a lie though. All GUIs have modes all over the place. For example:
- When I click into a text field, I go into Insert mode.
- When I tab away from the text field, I'm in some sort of Select mode.
These are clearly different modes because keys will do different things depending on the situation (e.g. [Space] in Select mode will click the focused button, but in Insert mode will insert text into the focused text field).
The biggest gripe I have is that there is no differentiation between selection mode and regular mode, which makes line selection or line deletion more complicated than it has to be -- 'xd' will delete the current line, unless the current line is empty, in which case it will delete the next line.
The reason for that makes sense in kakoune's model, which is that when the cursor is sitting on the EOL of the current line, the trailing \n is selected, and 'x' will select until the next \n (to support moving forward if the current line is entirely selected).
Otherwise the model is very nice, and the programming model (which is basically "let shell scripts do the heavy lifting") is actually surprisingly nice for implementing extensions.
These days I tire of Terminal programming and have been wanting to escape it for more rich UIs, but while I have been searching I am confident my end choice must support modal editing and selection behavior akin to Kakoune - so I can replicate the UX of Kakoune. As it stands I imagine my choice will be Xi Editor, once it gets better support for modal editing and multiple cursors.
2015: https://news.ycombinator.com/item?id=10484653, https://news.ycombinator.com/item?id=9764028
Oh, wait: https://github.com/gbigwood/Clippo
/ \ _____________
| | / \
@ @ | I make Vim |
|| || | much more |
|| || <--| friendly |
|\_/| | and easy. |
I’d like to try out the paradigm without losing my current productivity.
Of course. I just don’t think it has been done yet. Was tempted to try it myself.
I'd consider switching if there was a viable plugin for my current main editor or, better yet, something similar that NeoVim is trying to achieve (i.e. running actual vim as background process for these plugins instead of emulating).
Does Kakoune feature IDE-style omnicompletion? Like Elixir module name and function completion.