Every time I see a new text editor announced for programming, I find that is just a rehash pf unstructured text editing functionality. Programming languages are heavily structured, and code transformations between text and syntax tree forms have been implememted numerous times. So why the focus on editing plain text instead of trying to create an editor that actually transforms the syntax tree directly? I don't know what the UI would look like, but an editor that is based on refactoring operations instead of direct text manipulation might end up being a very powerful tool.
Structural editors are great, and normal text-based programming editors should probably support the same kinds of transforms, both precisely and fuzzily.
But a typical editing session will go through a lot of "invalid" states by design. Trying to enforce that structure is preserved at all times is a hindrance in many scenarios.
And further, if you bake structure into your editor in that way, it's much harder for anyone to invent new structures. Having good tools for unstructured text editing is valuable as, if nothing else, a fallback for when your structured editor doesn't understand the language you're editing.
Invalid states should only need exist in terms of virtual placeholders for elements required by the grammar, but not filled in by the user. I have a (unsupported) suspicion that directly editing a syntax tree when gaps in its structure ate allowed is no more cumbersome than editing the textual representation.
My understanding is that tools like Eclipse and Resharper work on pretty similar models internally to prevent complete failure to understand a code file while it is being mangled by the user.
Yes, but that requires a lot of language-specific work and heuristics to make work, and there are still a lot of places where the approach falls down. (Source: I work on precisely that sort of tool for C++.)
So you need the text-based fallback here, and you still need it anyway for the case of editing something a structure the editor doesn't know.
C++ is the worst possible language in this case. Its complexity is immense and the C preprocessor layered on top makes a straight mapping between code and syntax tree impossible to achieve in general. Simpler languages like Java or C# (at least relative to C++) allow such syntax tree based tools to reach much, much further. I do believe that it should be possible to build an editor for "nice" languages of that kind that is entirely based on editing the syntax tree.
All the biggest gains I've seen in editors are, in order of importance, inline doc lookups, easy local file search with file-customisable ignores, quick file opening with fuzzy search and Emmet abbreviations.
Does anyone know how Kakoune does in terms of these features? They're all much more important to me than say, syntax highlighting, which I find neither here nor there.
Kakoune doesn't come with any of these built in, however kak-lsp [1], the language server protocol client implementation, is fairly mature, and I wouldn't be surprised if it supported inline doc lookups. Certainly kakoune provides the facilities needed to implement that.
Cross-file grepping, and fancy fuzzy finders are considered beyond the scope of the editor, but the wiki has some tips for integrating a separate fuzzy finder program into kakoune [2].
Emmet would be super easy to implement but it just hasn't been yet to my knowledge.
Most key strokes in vim have roughly the same meaning in kakoune. My switch to kak two years ago was quite easy, maybe a week or two until I felt as comfortable – even though I used vim for nearly a decade. So I really recommend to at least try it, if you want to.
I have yet to "invest" in a terminal editor, so but I feel like it is impossible to choose.
They all have a steep learning curve and it seems like you need to climb pretty far up that curve before you can even judge if it is worth it to begin with.
Exactly, I really like the ideas, it seems to be 'vim, done rationally', but the vim muscle memory is just too ingrained, and I have quite a few custom keys bound for things like kicking off a test run, adding 'focus' flags to a current test etc, and then multi windows/panes, and plugins like nerd-tree, git tools like fugitive, gitgutter, etc, etc
Playing with it for a while did prompt me to look into and adopt vim visual mode, which I've never really used (was it even present if vi on ttys?). It's a step closer to the more rational (to me) 'selection, action' ordering.
This is exactly my position too. I really like the concept of kakoune, but vim is everywhere.
I can install keybinds for it in any editor on the planet, there's at least a vi on any system I happen across, things like qutebrowser ships with vim bindings by default, etc. etc.
Vim really isn't everywhere, though, in any meaningful sense. I see this claim frequently, but if you're a Vim power user, using it as your primary IDE, the stock configuration is unusable. A fully-customized Vim setup bears very little resemblance to a vanilla/default Vim setup, and the default can't be used for anything more than quick, tiny changes.
Also, how often do you use a brand-new clean system without any extra software installed? You might regularly do this if you're a sysadmin/devops person, but in that case, you ought to be using Ansible or something to bootstrap the machine to a robust state, and that would include customizing Vim if you rely on it heavily. The "quick edit to system config files" use case for Vim is also not the same as the "software development environment" use case. You can get by with unconfigured Vim in this scenario, but it doesn't obviate the need for a complete configuration if you plan to do intense editing later.
The fallacy that "Vim is everywhere" is perpetuated by people who don't use Vim for software development.
I don't know. I think the stock vim is pretty good, and loads of power users tend more towards the 'no plugins' than the 'all the plugins' end of the spectrum.
I started with a much bigger load of plugins than I use now, and I don't think I'm unusual in that. The stock settings and workflows, once you understand them, are usually better. The only exception is really for frills - like, a plugin that helps with composing regexes, or language-specific IDE stuff, or a pretty documentation browser.
Not to mention, it's really very quick to get all your normal plugins set up. I have a git repo that I just clone.
I tried this editor a while ago and immediately was able to understand their model for modal editing. Once you've gotten it, it's hard to not wish vim worked this way.
The problem is, vim is everywhere, and Kakoune isn't. :(
I recall someone in /r/Emacs pointing out that Emacs keybindings already implement Kakoune's "object then verb" philosophy. For instance, to delete text from current position until next occurrence of a letter z, you'd do C-SPC C-s z RET C-w [0]. C-SPC C-s z RET is the object part (C-SPC - start selection (but see [0]), C-s - start incremental search, z - find next z, RET - confirm you found what you were looking for). C-w is the verb part - cut region. If you want to cut until the n-th occurrence of z, just press C-s a few times after entering z.
--
[0] - C-s z RET C-w, if you're not using transient-mark-mode, aka. a visually marked, explicit selection common to most editors. With transient-mark-mode disabled, there is always a region between mark and point, and after accepting a search with RET, C-s drops a mark at the place you were when you started the search. transient-mark-mode is active by default (probably to reduce learning curve); working without it is weird at first, but also rewarding in terms of efficiency.
> Because of the verb followed by object grammar, vi changes are made in the dark, we dont see their effect until the whole editing sentence is finished. 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.
Or just do . (full stop/period), which will repeat the last command, and in this case delete to the f you want.
Also, if you want to see what you’re working with before you make a change in vim you can always use visual mode.
So the example given, dtf would become vtfd. That’s one extra key stroke but realistically if you can touch type you won’t notice. You can expand that selection with ; for the next t.
Personally I’d use dtf and then just use undo if its not what I want. I’d also use dot repeat command, gcf or a visual column to act on multiple selections.
True. An alternative if you want to see all your selections highlighted would be to turn search highlighting using set incseach and hlsearch.
Use / to first select what you want to change. Then use cgn to make a change and . to repeat it. n will skip a change.
This still might not be exactly what you want and that’s fine. It’s always good to try new ideas and new software but for me vim gives me plenty of options already.
As kak has roughly the same key bindings as vim, if you found vim unbearable, you'll have problems with kak, too. However, I'm not sure what issues you think of, I've used vim/kak with a qwertz layout without problems. Just re-assign äöü.
Every time I see a new text editor announced for programming, I find that is just a rehash pf unstructured text editing functionality. Programming languages are heavily structured, and code transformations between text and syntax tree forms have been implememted numerous times. So why the focus on editing plain text instead of trying to create an editor that actually transforms the syntax tree directly? I don't know what the UI would look like, but an editor that is based on refactoring operations instead of direct text manipulation might end up being a very powerful tool.
Structural editors are great, and normal text-based programming editors should probably support the same kinds of transforms, both precisely and fuzzily.
But a typical editing session will go through a lot of "invalid" states by design. Trying to enforce that structure is preserved at all times is a hindrance in many scenarios.
And further, if you bake structure into your editor in that way, it's much harder for anyone to invent new structures. Having good tools for unstructured text editing is valuable as, if nothing else, a fallback for when your structured editor doesn't understand the language you're editing.
Invalid states should only need exist in terms of virtual placeholders for elements required by the grammar, but not filled in by the user. I have a (unsupported) suspicion that directly editing a syntax tree when gaps in its structure ate allowed is no more cumbersome than editing the textual representation.
My understanding is that tools like Eclipse and Resharper work on pretty similar models internally to prevent complete failure to understand a code file while it is being mangled by the user.
Yes, but that requires a lot of language-specific work and heuristics to make work, and there are still a lot of places where the approach falls down. (Source: I work on precisely that sort of tool for C++.)
So you need the text-based fallback here, and you still need it anyway for the case of editing something a structure the editor doesn't know.
C++ is the worst possible language in this case. Its complexity is immense and the C preprocessor layered on top makes a straight mapping between code and syntax tree impossible to achieve in general. Simpler languages like Java or C# (at least relative to C++) allow such syntax tree based tools to reach much, much further. I do believe that it should be possible to build an editor for "nice" languages of that kind that is entirely based on editing the syntax tree.
For some languages what you suggest already exists. Check out, for example, parinfer [1] for Lisp and relatives.
https://shaunlebron.github.io/parinfer/
https://news.ycombinator.com/item?id=13773813
All the biggest gains I've seen in editors are, in order of importance, inline doc lookups, easy local file search with file-customisable ignores, quick file opening with fuzzy search and Emmet abbreviations.
Does anyone know how Kakoune does in terms of these features? They're all much more important to me than say, syntax highlighting, which I find neither here nor there.
Kakoune doesn't come with any of these built in, however kak-lsp [1], the language server protocol client implementation, is fairly mature, and I wouldn't be surprised if it supported inline doc lookups. Certainly kakoune provides the facilities needed to implement that.
Cross-file grepping, and fancy fuzzy finders are considered beyond the scope of the editor, but the wiki has some tips for integrating a separate fuzzy finder program into kakoune [2].
Emmet would be super easy to implement but it just hasn't been yet to my knowledge.
[1] https://github.com/ul/kak-lsp
[2] https://github.com/mawww/kakoune/wiki/Fuzzy-finder
I really like Kakoune and its ideas. But I've invested too much into vim to switch at this point :(
Most key strokes in vim have roughly the same meaning in kakoune. My switch to kak two years ago was quite easy, maybe a week or two until I felt as comfortable – even though I used vim for nearly a decade. So I really recommend to at least try it, if you want to.
I have yet to "invest" in a terminal editor, so but I feel like it is impossible to choose.
They all have a steep learning curve and it seems like you need to climb pretty far up that curve before you can even judge if it is worth it to begin with.
It is worth it, though not necessarily for improving the things you care about now.
Exactly, I really like the ideas, it seems to be 'vim, done rationally', but the vim muscle memory is just too ingrained, and I have quite a few custom keys bound for things like kicking off a test run, adding 'focus' flags to a current test etc, and then multi windows/panes, and plugins like nerd-tree, git tools like fugitive, gitgutter, etc, etc
Playing with it for a while did prompt me to look into and adopt vim visual mode, which I've never really used (was it even present if vi on ttys?). It's a step closer to the more rational (to me) 'selection, action' ordering.
This is exactly my position too. I really like the concept of kakoune, but vim is everywhere.
I can install keybinds for it in any editor on the planet, there's at least a vi on any system I happen across, things like qutebrowser ships with vim bindings by default, etc. etc.
Vim really isn't everywhere, though, in any meaningful sense. I see this claim frequently, but if you're a Vim power user, using it as your primary IDE, the stock configuration is unusable. A fully-customized Vim setup bears very little resemblance to a vanilla/default Vim setup, and the default can't be used for anything more than quick, tiny changes.
Also, how often do you use a brand-new clean system without any extra software installed? You might regularly do this if you're a sysadmin/devops person, but in that case, you ought to be using Ansible or something to bootstrap the machine to a robust state, and that would include customizing Vim if you rely on it heavily. The "quick edit to system config files" use case for Vim is also not the same as the "software development environment" use case. You can get by with unconfigured Vim in this scenario, but it doesn't obviate the need for a complete configuration if you plan to do intense editing later.
The fallacy that "Vim is everywhere" is perpetuated by people who don't use Vim for software development.
I don't know. I think the stock vim is pretty good, and loads of power users tend more towards the 'no plugins' than the 'all the plugins' end of the spectrum.
I started with a much bigger load of plugins than I use now, and I don't think I'm unusual in that. The stock settings and workflows, once you understand them, are usually better. The only exception is really for frills - like, a plugin that helps with composing regexes, or language-specific IDE stuff, or a pretty documentation browser.
Not to mention, it's really very quick to get all your normal plugins set up. I have a git repo that I just clone.
This is a solid point. I used Vim for years but kept a whole repo of configuration; setup from scratch took a long time.
Eventually I found myself not adding key bindings because $random_server wasn’t gonna have those.
I tried this editor a while ago and immediately was able to understand their model for modal editing. Once you've gotten it, it's hard to not wish vim worked this way.
The problem is, vim is everywhere, and Kakoune isn't. :(
This is also my problem. Additionally I couldn't work out how to create language-specific rules in the config (tab width, spaces, indenting etc).
I want to switch but need to make the process a bit smoother.
I make heavy use of the "visual select, [adjust selection], then do verb" pattern in vim, for the exact reasons that this blog posts describes.
It sounds like I should try Kakoune...
I'm so excited about Kakoune! I hope it manages to achieve critical mass along with a booming plug-in ecosystem. As it is, things are pretty lonely.
I've just played a bit with it, and it looks really good. What would rock is an Evil-like implementation on top of Emacs...
I recall someone in /r/Emacs pointing out that Emacs keybindings already implement Kakoune's "object then verb" philosophy. For instance, to delete text from current position until next occurrence of a letter z, you'd do C-SPC C-s z RET C-w [0]. C-SPC C-s z RET is the object part (C-SPC - start selection (but see [0]), C-s - start incremental search, z - find next z, RET - confirm you found what you were looking for). C-w is the verb part - cut region. If you want to cut until the n-th occurrence of z, just press C-s a few times after entering z.
--
[0] - C-s z RET C-w, if you're not using transient-mark-mode, aka. a visually marked, explicit selection common to most editors. With transient-mark-mode disabled, there is always a region between mark and point, and after accepting a search with RET, C-s drops a mark at the place you were when you started the search. transient-mark-mode is active by default (probably to reduce learning curve); working without it is weird at first, but also rewarding in terms of efficiency.
Thank you for this!
> Because of the verb followed by object grammar, vi changes are made in the dark, we dont see their effect until the whole editing sentence is finished. 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.
Or just do . (full stop/period), which will repeat the last command, and in this case delete to the f you want.
Repeat will only fix this particular case. If you did "dtf" and wanted "dff", repetition won't help.
Kakoune is kinda like vim in visual mode (or block visual) with multiple cursors.
> Repeat will only fix this particular case. If you did "dtf" and wanted "dff", repetition won't help.
My point wasn't that repetition is a panacea, but that the example in the article isn't a good one.
Also, if you want to see what you’re working with before you make a change in vim you can always use visual mode.
So the example given, dtf would become vtfd. That’s one extra key stroke but realistically if you can touch type you won’t notice. You can expand that selection with ; for the next t.
Personally I’d use dtf and then just use undo if its not what I want. I’d also use dot repeat command, gcf or a visual column to act on multiple selections.
Unfortunately, visual mode still only gives you a single selection.
True. An alternative if you want to see all your selections highlighted would be to turn search highlighting using set incseach and hlsearch.
Use / to first select what you want to change. Then use cgn to make a change and . to repeat it. n will skip a change.
This still might not be exactly what you want and that’s fine. It’s always good to try new ideas and new software but for me vim gives me plenty of options already.
Off Topic: None of the Video works on the site works in Safari as they are all webm.
I don't think it's a webm thing, they're broken for me in Chrome and FF as well.
I can't find any information about the keyboard issues vim has with eg. German layout. Does this editor suffers the same problems?
As kak has roughly the same key bindings as vim, if you found vim unbearable, you'll have problems with kak, too. However, I'm not sure what issues you think of, I've used vim/kak with a qwertz layout without problems. Just re-assign äöü.
I use the us-intl keyboard layout with an us keyboard, which works great for English and German text without switching layouts (I am German).
Is there anything here for emacs users? ;) This is really an interesting thread.
I love the ASCII arty Clippy for tool tips!
Not for Windows.
"Modal editor · Faster as in less keystrokes · Multiple selections · Orthogonal design"
I love it when software developers assume everybody else knows what their software runs on. SMH.
I love it when users believe the author of a FOSS package is obligated to support their operating system natively, and that Cygwin is not good enough.
I think the maintainer runs it on Windows using cygwin on a daily basis.
The examples are obviously in a terminal so you should expect it to not work on Windows.
There are lots of screenshots of vim running in a terminal and yet it works fine on Windows.
The readme says it works on Cygwin.
and I bet it would also work in WSL