[HN Gopher] Why Kakoune - The quest for a better code editor (2016)
___________________________________________________________________
Why Kakoune - The quest for a better code editor (2016)
Author : r3trohack3r
Score : 57 points
Date : 2023-06-21 20:50 UTC (2 hours ago)
(HTM) web link (kakoune.org)
(TXT) w3m dump (kakoune.org)
| BaculumMeumEst wrote:
| I tried using Kakoune as a daily driver for a while. I still bust
| it out now and then when there's something I want to do that
| would _really_ benefit from multiple cursors or structured
| regular expressions, but there's things that made me ditch it as
| my main editor:
|
| 1) Lack of windowing. I understand the pitch of radical
| simplicity by leaving this to the terminal editor, but it's just
| annoying as shit trying to write windowing configurations for
| different terminal editors. Something like making a window split
| and hopping between them shouldn't feel hacky and weird.
|
| 2) Extending the editor with Kakscript. Posix shell scripting is
| already something I do as little as possible, it's pretty much
| the worst programming language I can think of. Scripting kakoune
| uses shell scripting but it's far even worse, you descend into
| some weird un-debuggable eldritch horror mess of nested blocks of
| sh and eval mixing shell script semantics with kakoune editor
| state semantics.
|
| Actually editing text with it feels amazing, though. It's like
| the yin to Emacs' yang.
| bee_rider wrote:
| The site makes a surprisingly compelling pitch to me, a grumpy
| and set in his ways vim/Linux user.
|
| But, I don't know. It is hard to overcome the fact that vi clones
| have been around for a bazillion years, will almost certainly
| outlive all of us, and will always be in every repo.
| Y_Y wrote:
| I don't usually feel the need to spread religious truths to the
| masses, but I'd be happy to know to that it was because of me
| that someone learned that the best vi(m) really is emacs in
| evil-mode.
| behnamoh wrote:
| With recent integration of Copilot Chat in vscode, I'm less
| inclined to use Neovim or any terminal based editor. I think
| terminals had a time and place, but it's time we moved on to
| tools that are more user friendly and provide better features.
| sublinear wrote:
| > I think terminals had a time and place
|
| This is far beyond just an opinion about text editors. The
| terminal isn't going anywhere. It's the fallback, or sometimes
| the only, interactive mode available. Many developers use both
| vscode and vim on a daily basis, including myself. I see them
| as the best editors in their respective environments.
| davidatbu wrote:
| I just skimmed the release blog post for Copilot Chat, and I
| don't see why it can't be implemented in a terminal based
| editor. Copilot itself was.
| imbnwa wrote:
| TUI vs GUI seems orthogonal here, there are Copilot plugins for
| Neovim. Microsoft deciding what capabilities to make exclusive
| to its editor GUI is just vendor lock-in, not a fundamental
| refutation of the paradigm of modal TUI editors.
| sethrin wrote:
| I've been using the vim vscode plugin in vscode-nightly with
| Copilot Chat for a few weeks. I'm far from a vim expert, but I
| think you don't understand the point of vim, which is perhaps
| best understood as a language for text manipulation. Also, I
| have not found the chat feature of Copilot to be particularly
| useful.
| tester457 wrote:
| There's no reason why GUI tools can't embrace modal editing.
| acaloiar wrote:
| > I think terminals had a time and place, but it's time we
| moved on to tools that are more user friendly and provide
| better features.
|
| The terminal is not an impediment to "better features", and
| "user friendliness" is purely a subjective matter.
|
| I find VSCode deeply unfriendly to my preferred method of
| editing code, and I imagine VSCode users find vim, kakoune, and
| emacs similarly unfriendly to their preferred method of editing
| code. Nobody is wrong in their findings -- what one finds
| unfriendly is objectively true to them.
|
| But to say that I find VSCode deeply unfriendly is it not the
| same as your implying that terminals preclude "better" features
| and user friendliness. I'm simply recognizing preference, while
| what what you're saying seems to discount my (and that of many
| others) preference.
|
| [edited for grammar and clarity]
| triyambakam wrote:
| We? Speak for yourself
| chongli wrote:
| I spent a while trying Kakoune years ago and I have one minor
| complaint and one major complaint. Leading off with the minor
| complaint (because it's more annoying than severe): it is
| designed for multiple cursors editing as the default, rather than
| single. That is, many of the normal movement operations (such as
| search) have the side effect of leaving behind extra cursors,
| like little breadcrumbs, that take an extra keystroke to dismiss.
|
| Perhaps this makes sense for people who spend all day doing
| large-scale edits on highly structured files but it makes no
| sense for the kind of everyday editing that I do. Most of my time
| is spent either entering brand new text in bulk at the end of the
| file, or jumping around and making one-off changes via searching.
| When I want to do larger scale edits (I use vim, the editor kak
| was intended to succeed), I reach for :%s///gc to do
| confirmation-based global substitutions (or sometimes :g//s///gc
| instead of %s).
|
| So I really don't see the advantage of the multiple cursors
| approach, especially given that the files I'm working with are
| thousands of lines long. That is far too long to get any visual
| feedback benefit to using multiple cursors for whole-file
| substitutions.
|
| Now on to the major complaint. For some reason, the developers
| decided to buck the trend of plugin-based editors by not
| including a built-in scripting language with a nice API. Instead,
| people wanting to extend Kakoune are expected to write bash
| scripts (!?).
|
| Sorry, this is a colossal mistake that dooms the editor to
| irrelevance for the foreseeable future. They would have been far
| better off just picking a nice scripting language (how about
| Python, Ruby, or Lua) and building a really clean, sensible API
| for it. Bonus points for building in a package manager that can
| browse, fetch, install, and update plugins automatically. This is
| the one massive area of weakness for vim (VimScript? Ugh!) and
| they missed the boat!
| mananaysiempre wrote:
| > That is, many of the normal movement operations (such as
| search) have the side effect of leaving behind extra cursors,
| like little breadcrumbs, that take an extra keystroke to
| dismiss.
|
| Uh, no? Unless you're talking about undo which can indeed be
| annoying in that way when undoing a multicursor edit.
|
| In particular, search with / and its modified versions does not
| change the number of cursors, and neither does the next
| occurrence command, n. You have to explicitly say N (that is
| <s-n>) to add a new selection at the next occurrence rather
| than move the current one there, or use s and friends which are
| specifically geared to act on each match _within_ the current
| selection(s).
|
| Are you sure you aren't pressing something you shouldn't be out
| of (Vim) habit?
| skribanto wrote:
| As an alternative to gc you can page through selections with
| parens and alt-space to dismiss individual selections.
|
| its also easier to compose filters, eg matching all lines that
| contain regex A and B regardless of order. doing that with vim
| regex is kind of annoying and it gets programming worse the
| more filters you need to add
|
| Also its not bash specifically. You can send kak commands to
| the kak session from any programming language. As an example
| kak-lsp is in rust
| chongli wrote:
| _As an alternative to gc you can page through selections with
| parens and alt-space to dismiss individual selections._
|
| And that's great, it means kakoune is capable of
| accomplishing the same task via an equivalent multiple-
| cursors trick.
|
| But it's not the way my mind works. It forces me to go
| through and prune the set of cursors before I start making
| the substitution. I don't want to do that! I want to write
| the text of the substitution first (for the common case) and
| then y or n to yay/nay each substitution because often I
| don't know (and don't want to think about) everything my
| search pattern matched.
|
| _its also easier to compose filters, eg matching all lines
| that contain regex A and B regardless of order_
|
| I can count on one hand the number of times I really needed
| to do that in the two decades I've been using vim.
|
| This is really the crux of the issue with Kakoune. It takes
| the good enough philosophy of vim's composable count-motion-
| commands and tries to achieve apotheosis with a visual-
| motion-multiple-cursors scheme. In search of the perfect tool
| to let an octopus to edit the file everywhere at once, it
| leaves us humans behind. It also ignores the lessons of
| "Worse is Better" [1] in pursuit of philosophical purity.
|
| [1] https://en.wikipedia.org/wiki/Worse_is_better
| adrusi wrote:
| Kakoune is scripted over IPC, not bash scripts. The
| configuration language has some built in functionality for
| embedding bash scripts, and for smaller plugins or one-off
| personal customization, yeah you can do everything in a bash
| script.
|
| But absolutely nothing forces you to implementing plugins as
| shell scripts! kak-lsp, which provides great integration with
| language servers, is written in rust. Peneira, a fuzzy finder
| tool, is implemented in python. People have written libraries
| for various languages that make interfacing with kakoune from
| your language of choice quite convenient.
|
| The decision to make all extension functionality work over IPC
| instead of an embedded scripting language means everything that
| the editor is capable of can be controlled by any piece of
| software over a thoughtfully crafted and well-documented
| interface. Also the extensions people write for kakoune end up
| also serving as general purpose utilities that can be
| integrated into stuff other than kakoune.
|
| I've always considered kakoune's approach to extensibility the
| main selling point of the editor. It has quite phenomenal
| plugin support for such a niche editor, and it's way easier to
| make your own plugin than it is with other editors because of
| how streamline the API is.
| dang wrote:
| Related:
|
| _Kakoune Code Editor_ -
| https://news.ycombinator.com/item?id=29975052 - Jan 2022 (170
| comments)
|
| _Kakoune, a punk-rock text editor_ -
| https://news.ycombinator.com/item?id=24716187 - Oct 2020 (2
| comments)
|
| _What you could steal from the Kakoune code editor, and get away
| with_ - https://news.ycombinator.com/item?id=24685267 - Oct 2020
| (94 comments)
|
| _Kakoune - A Modal Text Editor_ -
| https://news.ycombinator.com/item?id=19313794 - March 2019 (58
| comments)
|
| _Why Kakoune - The quest for a better code editor_ -
| https://news.ycombinator.com/item?id=17781780 - Aug 2018 (45
| comments)
|
| _Why Kakoune - The quest for a better code editor_ -
| https://news.ycombinator.com/item?id=13165919 - Dec 2016 (327
| comments)
|
| _Kakoune: a better code editor_ -
| https://news.ycombinator.com/item?id=13152499 - Dec 2016 (2
| comments)
|
| _Kakoune - An experiment for a better code editor_ -
| https://news.ycombinator.com/item?id=10484653 - Oct 2015 (34
| comments)
|
| _Mawww 's experiment for a better code editor_ -
| https://news.ycombinator.com/item?id=9764028 - June 2015 (15
| comments)
| pizzalife wrote:
| Anyone know the font in those videos? I think it looks pretty
| good.
| imbnwa wrote:
| I have tried my hand at Helix, a Kakoune-derivative, but I'm
| immensely bothered by the selection re-drawing as I move around:
| it creates visual noise. When I move, I just want to move; when I
| act, I just want to act. The problem of "maybe I wanted to delete
| 4 rather than 5 words" tends to not come up often enough to
| demand a solution as common programming notational practice tends
| to establish very obvious boundaries, e.g. df= (delete to the
| assignment operator), dfP (delete to first capital P, where maybe
| I'm renaming a method getFilePath with my cursor on the character
| 't'), d$ (delete to end of line), etc
| ufo wrote:
| I love kakoune's client-server design. Instead of terminal splits
| abd panes (which I can never remember the shortcuts), I ca open
| multiple terminal windows.
|
| My main gripe with kakoune is the extension model. Plugins run in
| a separate process which interacts with the editor by printing
| kakoune commands to standard output. Marshalling data and proper
| string escaping is a pain. Not to mention that many plugins are
| in bash, because it's the minimum common denominator.
| ltr_ wrote:
| is there a thing like rlwrap or "kakkeys" for zsh (or in the
| browser like vimium)? i use kak as my main editor, but i don't
| like to mentally switch to vi keys for anything else every time.
| galkk wrote:
| I find this part very compelling vi basic
| grammar is verb followed by object; it's nice because it matches
| well with the order we use in English, "delete word". On the
| other hand, it does not match well with the nature of what we
| express: There is only a handful of verbs in text editing
| (delete, yank, paste, insert... ), and they don't compose,
| contrarily to objects which can be arbitrarily complex, and
| difficult to express. That means that errors are not handled
| well. If you express your object wrongly with a delete verb, the
| wrong text will get deleted, you will need to undo, and try
| again. 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.
|
| Unfortunately, I'd rather see this as an alternative input mode
| in vim/vscode/nvim than separate editor, so I won't need to throw
| away all knowledge/plugins/dotfiles accumulated over time, than
| switching to completely new editor. Baggage is hard.
| Conscat wrote:
| I primarily used Kakoune for 2 months a few years ago. I loved
| its featureful regex engine which made certain macros much MUCH
| easier to write than Emacs functions. I also loved the selection-
| first editing model and have reimplemented that in Emacs and VS
| Code. But Kakoune was far too basic for me to get much serious
| C++ work done. You have to use external TUIs and CLIs constantly,
| and obviously those all have no integration with your Kakoune
| configuration.
| zokier wrote:
| If kakoune sparks your interest, you might also want to check out
| Helix, a new editor inspired by Kakoune in some parts
| dang wrote:
| Discussed a few times:
|
| _More hindsight on Vim, helix and kakoune_ -
| https://news.ycombinator.com/item?id=36066347 - May 2023 (1
| comment)
|
| _Helix 23.03_ - https://news.ycombinator.com/item?id=35384691
| - March 2023 (93 comments)
|
| _Helix 22.12_ - https://news.ycombinator.com/item?id=33890655
| - Dec 2022 (40 comments)
|
| _Helix: Post-Modern Text Editor_ -
| https://news.ycombinator.com/item?id=33494840 - Nov 2022 (166
| comments)
|
| _Helix: A Neovim inspired editor, written in Rust_ -
| https://news.ycombinator.com/item?id=33147270 - Oct 2022 (306
| comments)
|
| _Helix: A post-modern text editor_ -
| https://news.ycombinator.com/item?id=33039390 - Sept 2022 (2
| comments)
|
| _Helix, Terminal Modal Editor_ -
| https://news.ycombinator.com/item?id=30847041 - March 2022 (2
| comments)
|
| _Helix 0.5 released (Kakoune like terminal text editor)_ -
| https://news.ycombinator.com/item?id=29043889 - Oct 2021 (2
| comments)
|
| _Helix: a post-modern modal text editor_ -
| https://news.ycombinator.com/item?id=27358479 - June 2021 (365
| comments)
| jeltz wrote:
| What does Helix do that Kakoune doesn't?
| tester457 wrote:
| Here's a good comparison of the two.
| https://news.ycombinator.com/item?id=29976369
| lwhsiao wrote:
| From: https://helix-editor.com/
|
| > Mainly by having more things built-in. Kakoune is
| composable by design, relying on external tooling to manage
| splits and provide language server support. Helix instead
| chooses to integrate more. We also use tree-sitter for
| highlighting and code analysis.
___________________________________________________________________
(page generated 2023-06-21 23:00 UTC)