I’m one of the people who don’t like it, and I really don’t like it. It’s jarring and breaks my flow, and >90% of the time I know what I’m typing ahead of time.
Reminds me of how Apple built suggestions support into the Touch Bar. Seems kind of pointless to me, as all the people who would be able to use it probably type fast enough that they don’t even need it.
I’m pretty sure most notifications Kakoune displays onscreen are contained within the status bar—same as Vim—so they don’t get in the way of editing. (The screencast might make things a bit clearer.) Any pop-ups can be disabled fairly easily, as per this thread; nevertheless, I completely agree with you with regard to them. But who knows, maybe that’s what command-line editors need to reel in those last few people who are still using graphical editors.
As a serious vim user: This is genuinely cool! It might be too late for my fingers to ever abandon Vim, but I applaud any effort to make modal editing more learnable and ubiquitous. The object->verb ordering is probably the single biggest contribution of the modern OOP language world and it just makes sense for text editing commands too.
Some constructive criticism: My visceral reaction to seeing Clippy is so bad that it almost makes me not want to read anything else on your pages or watch your videos. You may consider avoiding Clippy and his negative associations.
The new grammar may bring some benefit, but text objects are IMO not a real problem. Let’s see if I get around to testing this, but I’m wary of it, because Vim takes a long time to master, so this will probably too.
My gut tells me it’s trading something off for something else and the individual user’s mileage will certainly vary.
I’ve been using it as my main editor for monthes now, and it works extremelly well! Some features still need some polishing, but it has replaced vim entirely for me.
Some hints I’d give to people wanting to do the same: learn and use multiple cursors! I use them instead of macros as they work interactively.
On the bad side, syntax HL is turned on by default (that my tastes though!), you cannot tab-complete file names in the status line yet (eg, :e name<tab>), and some characters are not possible to type (even whem pressing ^V). Otherwise, I feel more efficient with it than I was with vim.
I haven’t, but it seems like the most obvious difference is the lack of overlays in vis.
Also, that it’s a real pain to install the Lua library that’s required for syntax highlighting in vis (it’s called lpeg) if you’re not on one of the supported distributions.
I did while it was still rather young and had quite a few bugs rendering it pretty unusable for me, but I’m sure it’d be worth checking in again when they reach v0.3 or few milestones down the road.
I wish they wouldn’t dismiss Windows support. I can understand their reasons, but if I were to commit the time to learn a new way of modal editing, it would be nice if I could use it on all platforms I need to.
Oh, and I couldn’t help but think this is Yoda-Vim .. “till next f, delete”.
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
Wouldn’t you just press . to achieve the same effect?
Besides, unlike (n)vi, vim sort-of supports the object-verb model with v (visual selection), and it’s even adjustable in real time. vtf;d is “select until ‘f’, repeat movement (to next ‘f’), delete selection”.
This is one of those project ideas I’ve though about on and off for years, interleaved with the uneasy feeling that Vim (and my Vim configuration) is help together by shoestrings, and that maybe I should start using Sam or Acme.
The object before verb approach strikes me as potentially brilliant, though I’d need to try the editor for a bit before being sure. I could imagine running into mental issues with the Yoda phrasing, as @jibsen mentioned. It might be enough to think of it as ‘subject - verb’ instead and imagine the command to take the form of “this selection until the next ‘f’ deletes itself.”
The largest issue, of course, is the standard worse-is-better one: VIm keybindings are widely available for everything from web browsers to shells, and having to keep a second Vim-proximate language in my head for just my test editor seems unwieldy.
Have you tried spacemacs? Has all the good of strong vim bindings and quite extensive vim power features, but doesn’t feel quite as hacked together and fragile as vim+plugins does. The discoverability of the chords and the well thought out mnemonic combinations are a real win.
It’s changed a bunch but here is a decent video overview and here is the homepage. Install is quick and easy.
This is neat, and I’m all for improving the Vim user experience and integrating with the shell better, but unfortunately this doesn’t contain the kinds of improvements I’m looking for in an editor (yet).
The author seems to have missed why editors like Sublime and Atom took off: because they offered a simple but powerful editor in a clean interface that was easy to extend using simple languages. Atom takes this one step further, where the editor itself is extensible using HTML, CSS, and JavaScript. This is awesome and allows for infinite capabilities. I’m not seeing that here. I’d be curious what it would look like to take some of these ideas and integrate them into Atom.
The author seems to have missed why editors like Sublime and Atom took off: because they offered a simple but powerful editor in a clean interface that was easy to extend using simple languages.
That’s what Vimscript and Emacs Lisp were intended to do, though I suppose they’re not nearly as shiny as Sublime and Atom’s Python and JS (respectively).
Atom takes this one step further, where the editor itself is extensible using HTML, CSS, and JavaScript. This is awesome and allows for infinite capabilities. I’m not seeing that here.
That’s because this is a command-line editor. It would make no sense to support those three in an editor where formatting is limited to two weights and sixteen colors. Vimscript and Emacs do more than enough to facilitate advanced editor capabilities.
I’m pretty sure most of the reason people use Sublime and Atom is that they have the option of using them graphically and getting used to the commands over time, whereas with Vim and Emacs knowing the commands is prerequisite. But there’s still a reason command-line editors have stuck around, and it’s because all you really need your text editor to do is display text.
That post doesn’t really mention the reasons behind its claims. I’m a big supporter of Public Domain licensing. When evaluating CC0 vs Unlicense, I could only really find the mention of moral rights which are default copyright rights which are hard to intentionally relinquish:
IMO the biggest problem is that the license expects that jurisdictions that recognize copyright law, also have the concept of “Public Domain” which is not always the case, e.g. in Germany. For that reason, it will never be allowed to be used in larger German companies (for fear of being sued later).
I used to use the Beerware license for my stuff, but switched to Expat/MIT for similar reasons.
[Comment removed by author]
[Comment removed by author]
[Comment removed by author]
Sorry, my deleted comments were a reply to the wrong author :(
I think you’re the only one who can see “[Comment removed by author]”. All I see is your apology.
oh.
Reminds me of how Apple built suggestions support into the Touch Bar. Seems kind of pointless to me, as all the people who would be able to use it probably type fast enough that they don’t even need it.
I’m pretty sure most notifications Kakoune displays onscreen are contained within the status bar—same as Vim—so they don’t get in the way of editing. (The screencast might make things a bit clearer.) Any pop-ups can be disabled fairly easily, as per this thread; nevertheless, I completely agree with you with regard to them. But who knows, maybe that’s what command-line editors need to reel in those last few people who are still using graphical editors.
As a serious vim user: This is genuinely cool! It might be too late for my fingers to ever abandon Vim, but I applaud any effort to make modal editing more learnable and ubiquitous. The object->verb ordering is probably the single biggest contribution of the modern OOP language world and it just makes sense for text editing commands too.
Some constructive criticism: My visceral reaction to seeing Clippy is so bad that it almost makes me not want to read anything else on your pages or watch your videos. You may consider avoiding Clippy and his negative associations.
The new grammar may bring some benefit, but text objects are IMO not a real problem. Let’s see if I get around to testing this, but I’m wary of it, because Vim takes a long time to master, so this will probably too.
My gut tells me it’s trading something off for something else and the individual user’s mileage will certainly vary.
Clippy’s not that bad but it would nice if you could turn him off.
The code would suggest there’s a cat option if it bothers you that much:
https://github.com/mawww/kakoune/blob/5ff8245cc84a15d6a48bd2e19e4c70d4f8ae3f77/src/ncurses_ui.cc#L31
It is actually possible to turn it off entirely. I’ve been messing with kakoune and this is the first line in my kakrc:
They’re just following in the footsteps of Clippy for nvi.
Has anyone here ever tried https://github.com/martanne/vis ? I’d be curious to see how they compare.
I’ve been using it as my main editor for monthes now, and it works extremelly well! Some features still need some polishing, but it has replaced vim entirely for me. Some hints I’d give to people wanting to do the same: learn and use multiple cursors! I use them instead of macros as they work interactively.
On the bad side, syntax HL is turned on by default (that my tastes though!), you cannot tab-complete file names in the status line yet (eg,
:e name<tab>), and some characters are not possible to type (even whem pressing ^V). Otherwise, I feel more efficient with it than I was with vim.I haven’t, but it seems like the most obvious difference is the lack of overlays in
vis.Also, that it’s a real pain to install the Lua library that’s required for syntax highlighting in
vis(it’s calledlpeg) if you’re not on one of the supported distributions.I did while it was still rather young and had quite a few bugs rendering it pretty unusable for me, but I’m sure it’d be worth checking in again when they reach v0.3 or few milestones down the road.
I wish they wouldn’t dismiss Windows support. I can understand their reasons, but if I were to commit the time to learn a new way of modal editing, it would be nice if I could use it on all platforms I need to.
Oh, and I couldn’t help but think this is Yoda-Vim .. “till next f, delete”.
I believe you can get it working now on Windows with BoUoW (Bash on Ubuntu on Windows) or Cygwin.
Wouldn’t you just press
.to achieve the same effect?Unless you want to repeat the whole
d2tfwith., in which case you’d have to hit it twice every time you wanted to use it.Besides, unlike (n)vi, vim sort-of supports the object-verb model with
v(visual selection), and it’s even adjustable in real time.vtf;dis “select until ‘f’, repeat movement (to next ‘f’), delete selection”.With
dtfmaybe, but it won’t help withytf.And the result of the paste register will be different, too, with
dtf.This is one of those project ideas I’ve though about on and off for years, interleaved with the uneasy feeling that Vim (and my Vim configuration) is help together by shoestrings, and that maybe I should start using Sam or Acme.
The object before verb approach strikes me as potentially brilliant, though I’d need to try the editor for a bit before being sure. I could imagine running into mental issues with the Yoda phrasing, as @jibsen mentioned. It might be enough to think of it as ‘subject - verb’ instead and imagine the command to take the form of “this selection until the next ‘f’ deletes itself.”
The largest issue, of course, is the standard worse-is-better one: VIm keybindings are widely available for everything from web browsers to shells, and having to keep a second Vim-proximate language in my head for just my test editor seems unwieldy.
Have you tried spacemacs? Has all the good of strong vim bindings and quite extensive vim power features, but doesn’t feel quite as hacked together and fragile as vim+plugins does. The discoverability of the chords and the well thought out mnemonic combinations are a real win.
It’s changed a bunch but here is a decent video overview and here is the homepage. Install is quick and easy.
This is neat, and I’m all for improving the Vim user experience and integrating with the shell better, but unfortunately this doesn’t contain the kinds of improvements I’m looking for in an editor (yet).
The author seems to have missed why editors like Sublime and Atom took off: because they offered a simple but powerful editor in a clean interface that was easy to extend using simple languages. Atom takes this one step further, where the editor itself is extensible using HTML, CSS, and JavaScript. This is awesome and allows for infinite capabilities. I’m not seeing that here. I’d be curious what it would look like to take some of these ideas and integrate them into Atom.
That’s what Vimscript and Emacs Lisp were intended to do, though I suppose they’re not nearly as shiny as Sublime and Atom’s Python and JS (respectively).
That’s because this is a command-line editor. It would make no sense to support those three in an editor where formatting is limited to two weights and sixteen colors. Vimscript and Emacs do more than enough to facilitate advanced editor capabilities.
I’m pretty sure most of the reason people use Sublime and Atom is that they have the option of using them graphically and getting used to the commands over time, whereas with Vim and Emacs knowing the commands is prerequisite. But there’s still a reason command-line editors have stuck around, and it’s because all you really need your text editor to do is display text.
Of course it had to be released under an “unlicense” which makes it largely not distributable :-(
Could you elaborate? Why does this license make it not distributable?
Well, The GNU Project is happy with it but there are some criticisms of the license, for example see this post on Stack Exchange.
Update: The mailing list archive link in the Stack Exchange post above is incorrect - discussion is here.
That post doesn’t really mention the reasons behind its claims. I’m a big supporter of Public Domain licensing. When evaluating CC0 vs Unlicense, I could only really find the mention of moral rights which are default copyright rights which are hard to intentionally relinquish:
https://en.wikipedia.org/wiki/Moral_rights
I chose Unlicense due to its simplicity and my personal belief that people are strawmanning that scenario
IMO the biggest problem is that the license expects that jurisdictions that recognize copyright law, also have the concept of “Public Domain” which is not always the case, e.g. in Germany. For that reason, it will never be allowed to be used in larger German companies (for fear of being sued later).
I used to use the Beerware license for my stuff, but switched to Expat/MIT for similar reasons.