[HN Gopher] Why Kakoune
___________________________________________________________________
Why Kakoune
Author : rc00
Score : 127 points
Date : 2023-09-21 12:42 UTC (10 hours ago)
(HTM) web link (andreyor.st)
(TXT) w3m dump (andreyor.st)
| satvikpendem wrote:
| For those that have used Vim/Neovim, Kakoune, Helix and other
| terminal editors, which one is your favorite? I use VSCode and
| have been looking to switch, I use Neovim inside VSCode (without
| the emulation of something like VSCodeVim) [0] which is decent
| but that's mainly because I don't want to set up all the plugins
| for Neovim again. Helix seems interesting because most things are
| built like with VSCode, it just works(tm), but I have to learn a
| new keyboard control scheme.
|
| [0] https://github.com/vscode-neovim/vscode-neovim
| bern4444 wrote:
| I use NeoVim. I used Vim previously and just know the built in
| basics very well.
|
| NeoVim incorporating Lua as a first class language has allowed
| plugin authors to build plugins that are faster and better than
| plugins for Vim written in VimScript (or other languages like
| python/typescript which are much slower).
|
| There is a strong community for neovim on reddit, youtube, etc
| and plugin authors do a nice job of building tools that work
| with each other.
|
| Setting it up I agree is a pain, but once done its very little
| maintenance/work. Even when I've had to 'redo' my setup (eg
| switching package managers like vim plug to packer to lazy) its
| been easy and under 15 or so minutes.
|
| I edit minor things in my config every few months. Everything
| flows quite nicely now and breaking changes are far less common
| than they used to be (at least among the plugins I use).
|
| My vim config if you're curious (along with the rest of my
| dotfiles):
| https://github.com/sbernheim4/dotfiles/tree/master/vim
| dkarl wrote:
| I haven't used Kakoune, but I've used emacs, Neovim, and Helix.
| I love the simplicity of Helix and how easy it is to get it up
| and running with language servers. Emacs and Neovim have
| amazing ecosystems, but I'm not willing to devote the time
| needed to keep my setup working and do the labor of installing
| and configuring so many plugins. I actually switched from emacs
| to a mix of VSCode and JetBrains IDEs (PyCharm, DataGrip) but I
| sometimes find myself copy-pasting blocks of text into emacs
| when I need to do anything fancy or repetitive. I used a Neovim
| integration for VSCode for a while but found it annoyingly
| buggy.
|
| IDEs like VSCode and JetBrains seem to be in denial about
| coding being a text editing activity. Emacs and Neovim want you
| to take on a part-time job building and maintaining your own
| personal editor application out of a pile of spare parts. Helix
| to me is a very promising approach: a text editor that aspires
| to provide enough polished core features to be a productive
| coding environment.
| broscillator wrote:
| FWIW it took effort for me to choose and curate my nvim
| plugins, but there's almost 0 time and effort invested in
| maintaining it.
|
| Occasionally CoC will ask me to update it, that's running a
| single command. That's it, as long as you're not constantly
| looking for new tools and plugins (we've all been there),
| once you settle on your setup, there is no maintenance
| whatsoever.
| SushiHippie wrote:
| IMO learning the helix keybindings is definitely worth it.
| Install it, check with `hx --health` what LSPs you need and
| install these and that's it. And you still have so much
| configuration you _could_ do, but don 't really need.
| TeddyDD wrote:
| I'd probably use Helix if it had 1:1 Kakoune keybindings. Or
| even Vim bindings.
|
| Vim bindings are not the most consistent, but they are
| ubiquitous. Every program that offers Vim mode has very
| similar keymap. If modal text editor deviates from them, it
| better be for good reason.
|
| Kakoune bindings are very different from Vim, but they are
| provably and objectively [1] better, so that's fine. They are
| also more consistent and there is a clear idea behind the
| whole design. It's written down in documentation. You might
| prefer Vim or Emacs, but at least you can see that changes
| from well known Vim scheme are not made at whim.
|
| Helix keymap feels like it was improvised without any thought
| behind it. ,,Let's take Kakoune binds and add back visual
| mode cuz I feel like it." Currently, they are designed by
| committee in this GitHub issue[2]. I don't see any design
| notes and explanations why should I spend time learning Helix
| keymap.
|
| [1]: https://github.com/mawww/golf [2]:
| https://github.com/helix-editor/helix/issues/165
| SushiHippie wrote:
| To be fair, before I used helix, I only used neovims basic
| keybindings (hjkl, dd, ...) and nothing advanced, so I
| didn't really need to 'relearn' much, but I completeley
| understand when someone used a set of keybindings for some
| time it's really hard to switch.
| satvikpendem wrote:
| There is still no plugin support for Helix though right?
| That's what keeps bringing me back to VSCode, there is always
| something missing in each editor I look at. Same for VSCode
| though to be fair, it's sometimes slow on large files and
| especially when doing type checking, but it's a trade-off I'm
| making for its DX, I suppose.
| dkarl wrote:
| I like that Helix's approach is different, and I think the
| lack of plugins is essential for it to remain on its chosen
| path. If Helix got plugins, then soon enough everybody
| would be scratching all their itches using plugins, there
| would be no users for the core functionality, and it would
| be the same kind of ecosystem we already have for emacs and
| Neovim.
|
| What would be ideal for me, but probably not possible in
| reality, is an editor that cannibalizes popular plugins.
| So, if a feature is sorely lacking, the plugins appear, but
| eventually the core functionality grows to replace the
| plugins. A new user installs the editor and gets a rich set
| of features that are battle-tested and built to work
| together. What seems to happen in practice with emacs and
| Neovim is that the core never gets any bigger, so a new
| user gets zero benefit from those decades of work,
| experimentation, and discovery, until they invest the time
| to integrate dozens of disparate packages into their own
| setup which they will have to maintain themselves over
| time.
| eviks wrote:
| But that seems to happen in practice with emacs and vim,
| why would the newly designed editors follow the same
| rotten path, after all they've managed to break some
| significant conventions of those other editors?
|
| The other "in practice" side is that without plugins the
| editor will never get as good as a properly (though
| painfully, though less painfully with some preconfigured
| distribution) configured alternative one with plugins
| bobbyskelton41 wrote:
| There is a working prototype (that's gone as far as
| implementing a vim-dirvish picker):
| https://github.com/mattwparas/helix/tree/mwp-steel-
| integrati...
|
| The maintainers are collaborating with the dev and hope to
| get a PR open sometime this upcoming year.
| SushiHippie wrote:
| Curious what plugins would you want? The only thing I
| personally need are LSPs, so it's not a big problem for me.
| haolez wrote:
| I think the biggest benefit of going away from something like
| VSCode or IDEA is frictionless creation and integration of new
| tools. VSCode and IDEA usually require you to write plugins to
| achieve a deep level of customization for your needs, which
| causes a lot of friction. In an environment like Vim and Emacs,
| you can make quick scripts that create new features for your
| project that you wouldn't have created otherwise.
|
| I'm currently using VSCode, but I don't code a lot these days.
| If you are looking to explore a new paradigm like that, I would
| go with Emacs as a practical option (with vi bindings) and Acme
| as a way to open your mind (but not very practical).
| kaba0 wrote:
| How is this different than writing a plugin?
| xigoi wrote:
| Less ceremony. You literally just write some code and save
| it to a file.
| haolez wrote:
| The intermediate state where your "plugin" is just a one-
| off script that you wrote and ran in a single buffer,
| without a build system or IDE SDK.
| satvikpendem wrote:
| True, that is a benefit, but realistically though, I probably
| won't be writing any scripts or plugins myself for the editor
| I use, same as with VSCode, I just get them from others or on
| the Extension Marketplace.
| wrapperup wrote:
| I've used all except Kakoune. For me, Neovim is the one that
| stuck. Helix is cool, but having no plugins is a deal breaker
| (for now!) The onboarding experience is much nicer for sure,
| and Helix's LSP is way easier to set up than Neovim's.
|
| That being said, Neovim, once you get it set up, is great. The
| biggest hurdle for me was the config, but if you just start
| from scratch and make a light config (mines about 200-300
| lines, with LSP, hints, etc) you can get through it. And you
| never have to touch it again, since most likely you configured
| it in a way you like. Well unless you wanna add the occasional
| plugin. There are also distros of Neovim that contain a fully
| baked IDE-lite experience, but honestly those have extremely
| complicated config, and often IME don't feel nice and light.
|
| It's definitely not for everyone. There is that time investment
| to get started, but it's definitely been worth it for me.
|
| My config: https://github.com/wrapperup/nvim-config
| satvikpendem wrote:
| > _And you never have to touch it again, since most likely
| you configured it in a way you like._
|
| That was the issue for me, there actually is quite a bit of
| churn in the Neovim plugins ecosystem compared to VSCode
| (Packer vs Lazy for plugin management is just the latest
| iteration). I used to have Neovim plugins all built out but
| the churn was too much for me.
| lawn wrote:
| I think it's what you do with it.
|
| I've used vim-plug for over a decade and it's been working
| fine. Yes there has been a lot of churn within some
| plugins, but overall it hasn't been that bad in my opinion.
|
| And with lazy tracking plugin versions in a lock file, it's
| easy enough to pin plugins to a known good version whenever
| something breaks.
|
| (I finally rewrote my entire config, and lazy is vastly
| better than vim-plug. I should've done so sooner.)
| 59nadir wrote:
| > (I finally rewrote my entire config, and lazy is vastly
| better than vim-plug. I should've done so sooner.)
|
| What's better about it? I ask because I've been using
| `Plug` since I switched from pathogen (what feels like)
| an eternity ago and I don't really know any reason to
| switch because it just sort of works...? Every few years
| or whatever I'll overhaul the config (not a choice but it
| just sort of happens) and I'm curious whether switching
| plugin management plugin has a point.
| wrapperup wrote:
| Oh yeah for sure. I haven't had that happen to me, but when
| I dropped AstroNvim, I had a chance to start from fresh (on
| lazy).
|
| Small customized config also means smaller and more precise
| changes. I haven't touched mine in quite a long time, only
| usually to add that cool trick or plugin that pops up every
| so often.
| ilc wrote:
| I've used NeoVim, I was a long time emacs user in the 90's.
| Etc.
|
| Honestly: I use Jetbrains IDEs now. It is worth having the
| little integrated tools, like the debugger, etc.
|
| I have a nice NeoVim setup but it gets used less and less now.
| dpc_01234 wrote:
| I was using Kakoune for 3-4 years, and switched a year ago to
| Helix.
|
| Kakoune is OK, but:
|
| Some details of editing are too optimized for counting
| keystrokes in vim golf, less for thinking-free editing
| experience.
|
| Configuring and extending text editor with shell scripts is
| ridiculous.
|
| It's in C++. I want to be able to debug and submit changes to
| my most used dev tool and I don't want to be touching C++.
|
| Having said that, I still miss the visual-mode-first experience
| of Kakoune (most moves in Kakoune change/modify selection,
| while Vim/Helix have visual mode instead).
|
| Otherwise I think Helix already leaped over Kakoune in terms of
| functionality and polish, because it's just easier to
| contribute to (in Rust).
|
| BTW. The difference between Vim and Kakoune/Helix is not that
| big. For basic Vim modes in shells and other tools, I don't
| really notice it. `hjkl` works all the same.
| BaculumMeumEst wrote:
| Agreed on all points. And one more issue with Kakoune: while
| delegating all windowing functionality to the terminal
| emulator probably sounds great to the editor implementer, for
| a user it is fucking annoying. An editor should be able to
| manage splits and tabs. It should have a basic concept of
| some kind of UI pop ups.
|
| Kakoune can feel _amazing_ to use at times, but it is at the
| same time a case study on why brutalist minimalism isn't the
| best design goal.
| xcdzvyn wrote:
| Could I ask what Vim can do that Kakoune + Tmux can't?
|
| I don't doubt there's something, I've just never
| encountered it.
| broscillator wrote:
| nvim. There isn't much software I can say that _feels_ so
| comfortable to use for me.
|
| A lot of people look at the learning curve and decide it's not
| worth the time investment, just so they can save time later on
| when they're more comfortable with it.
|
| But to me it's not about time, it's about how smooth it feels
| to use, how I can translate thinking to typing/editing with the
| least friction possible, and nvim with my minimal set of
| plugins that I curated over years, that is it.
| oira-oira wrote:
| vis
| hiAndrewQuinn wrote:
| Helix is very cool, and I liked playing around with it. But it
| doesn't support Copilot, which is an instant deal killer for a
| lot of people, myself included.
|
| I'm sticking with Neovim, especially because I work close to a
| lot of embedded stuff where being handy with stock vim comes in
| handy quite frequently.
| klardotsh wrote:
| "For a lot of people"? I'm not saying your experience is
| invalid, I'm just curious how big the overlap of Codepilot
| users and potential Helix users is. I don't know anyone
| personally who _likes_ Codepilot, and only a few who have
| used it at all. To me it still seems to be a niche (and
| probably copyright law violating) product.
| Hammershaft wrote:
| Helix is easier to jump into as it supports a lot of useful
| code editing features out of the box, but Kakoune has a more
| elegant and discoverable modal editing experience.
| hn92726819 wrote:
| I have used all three. Vim for ~5 years, then kakoune for 2
| years, then helix for 2 months, and back to kak for 2 years
| (with no end in sight). Kakoune is my favorite and helix is
| very nice, and I would never go back to vim.
|
| Vim: + ecosystem is nice. Plugins and
| matching keybinds in ACE/codemirror/whatever was cool for
| interop + having vi or vim on any Linux box is nice
| - you have to have plugins for basic things like pcre, correct
| colors (csapprox), and ale - at least when I stopped
| using vim, the multiple cursors plugin was nothing near as good
| as the other two. It was tacked on to a single-cursor editor,
| and you can tell
|
| Hx (my knowledge is 1-2 years old): + felt
| completely natural coming from vim. If you use vim and don't
| want to warp your brain with new keybinds, try hx. It feels
| like vim+more. Kak feels like a different editor + many
| built-in features that require plugins in vim/kak +
| using LSP motions felt amazing + written in rust, which
| I love. The codebase is entirely readable and I contributed a
| patch after only about an hour first looking at it - hx
| didn't have motions for ()/<>/... Which I've come to rely on.
| Kak has m which is like Vim's f(v% if f was multiline -
| no advanced keybinds/bindsym in vim/map in kak. Config was toml
| so the most you could do was bind single chars to other single
| chars - no plugin support, though I found myself not
| really longing for any plugins because so much comes by default
| - occasional crashes due to off-by-one errors and .unwraps
| sprinkled around
|
| Kak: + editing feels amazing. Like the text
| is directly connected to your brain. This is because basically
| every action gives you feedback. For example, in vim, t(dt)
| gives you a cursor move and then the text is gone. t(v%d gives
| you feedback but takes way more keys, but in kak, md
| immediately selects the entire bracket after m and deletes it
| after d. Having visual feedback *as a requirement* (not an
| option like Vim's visual mode) is amazing. I didn't use hx
| enough to know if it feels like vim or kak in this regard
| + plugins exist. Kak-lsp is nice. Scripting your own keybinds
| feels more natural because the scripting language *is* the
| keybinds, contrary to vim. Basically imagine every keybind is
| like Vim's but with a :normal before it + multisel
| feels compltetly natural. Not like an extension to what you're
| doing, but everything is multisel, and you just happen to have
| n=1 selection sometimes +/- piping to external
| programs feels very natural. I have numerous scripts that take
| stdin and write to stout. In kak, I select whatever I want and
| just run |encode-url<ret> and it pipes every individual
| selection to my command and replaces them with my output. This
| is also bad because if I have 100 selections (not uncommon), it
| will spawn 100 shells to spawn my command 100 times -
| people keep saying it doesnt have a scripting language, which
| is misleading IMO. There are try blocks, %{} groups, and
| commands that you need to learn about. Look at hx if you're
| interesting in no scripting language. It reads a toml config
| file and that's it. - a little overreliance on shell.
| I don't even know if windows can run kak because it uses shell
| so much. On one hand it's nice because I know Shell. On the
| other hand, interop feels weird. You echo commands and kak
| reads your stdout and evaluates it. It's clever and cool, but
| something about it feels weird. - keybinds don't
| behavibe like vim or hx. You have to retrain your muscle
| memory, but IMO it's worth it. Using vim now though is painful
|
| Kak is great
| bern4444 wrote:
| I love that we have so many choices for editors. VSCode, Vim,
| NeoVim (+ vim distros like astro etc), emacs (+ emacs distros),
| Kakoune, Helix etc.
|
| Its awesome to have so many choices so everyone can pick the
| system that best fits them. It also encourages better tooling
| that can fit on top of any of these like the Language Server
| Protocol, TreeSitter etc which benefit everyone.
|
| Thanks to everyone for working on all these projects and tooling,
| its truly incredible.
| seanw444 wrote:
| It's definitely never been easier and more free to tinker and
| write code than now. Cool times.
| Conscat wrote:
| Kakoune has the nicest regex interaction I've ever used in a text
| editor. It's feature complete and accessible from a single
| keystroke out of the box. You can write key macros that input
| regex to do surprisingly complex motions without any scripting
| language.
| eviks wrote:
| That reads like a why not:
|
| > Kakoune made me learn Perl ... Awk ... POSIX sh ... regexes
|
| But these aren't great ergonomic tools, so it's not a good thing
| that Kakoune "requires" them, it's rather a testatment of how
| much it's lacking on its own
|
| (though haven't used Kak since it's unfortunately not x-platform,
| the selection first paradigm is totally a superior UI to the
| hidden vim ways)
| jwmcq wrote:
| Odd choice of words. I'd say that perl, awk, regex etc are
| great ergonomic tools - if anything _too_ ergonomic. The main
| problem with them - and the probable source of their bad
| reputations - is that the ease and comfort (the 'ergonomics')
| of just cobbling something together something that works and
| then throwing it out there does not encourage good engineering
| practices.
|
| Do I need good engineering practices in my day-to-day text
| editing? Mostly not for what I do myself, but I'm grateful that
| the maintainers of the emacs packages I use have better tools
| to work with.
| eviks wrote:
| > something together something that works
|
| or something that works... sometimes, and is indecipherable,
| so all the "ergonomics" of the initial cobbling phase
| disappears to reveal how unergonomic this really is
| jwmcq wrote:
| I feel you've missed my point - 'ergonomics' literally
| means 'efficiency and comfort', not 'future
| maintainability'. Regex does comfort. AWK does it. If you
| need to do a specific thing _right now_ , and you know
| them, then those tools are about as good as it gets. I'm
| not denying that those solutions will be horrible to grow
| and maintain, but that wasn't your point - that's why I
| said your choice of saying they weren't "ergonomic" was a
| bit odd. They are. That's the problem.
|
| Most of the custom text editing operations I do on a daily
| basis only need to work once. For that, a Regex is very
| 'ergonomic'. If I were writing an emacs package, I'd
| probably use something better - something less ergonomic,
| but easier to maintain.
|
| As an aside, I used to work in a machine shop and we had a
| well-designed system of pneumatic tubes throughout the
| warehouse powering spartan steel-handled drills that would
| give me calluses but reliably get the same jobs done the
| same way every day. At home, for the odd job I need to do,
| I use a cheap lithium drill with a nice grippy handle.
| Sometimes the ergonomic option is better because, right
| now, I just don't need to buy a compressor and run tubes
| through my house.
| [deleted]
| forgotpwd16 wrote:
| >so it's not a good thing that Kakoune "requires" them
|
| It doesn't. Author learned them because they made plugins and
| complex custom commands. The configuration language allows
| embedding shell scripts but Kakoune provides a POSIX interface
| so can use whatever language you want for plugins. Regexes are
| needed to be productive utilizing the full extend of text
| manipulation provided. Can do without but you miss a big reason
| for using Kakoune in first place.
| DixieDev wrote:
| I got quite annoyed with Neovim config at some point and tried
| out Kakoune, and ended up contributing some window splitting code
| to the main repo for Sway. I liked it quite a lot, but it's not
| built with Windows in mind so I ended up crawling back to Neovim.
| I'd be interested to hear of any Kakoune-like editors with better
| cross-platform support/design.
| welder wrote:
| I thought nobody used Kakoune anymore... maybe I'll go ahead and
| fix the bugs in the Kakoune WakaTime plugin
| https://github.com/WhatNodyn/kakoune-wakatime.
| Gualdrapo wrote:
| > Kakoune gives you:
|
| > Small and understandable core.
|
| > Proficiency with POSIX tools, and maybe even some programming
| languages other than sh.
|
| > Structural regular expressions as a central way of text
| manipulation.
|
| > With multiple selections created via regular expressions,
| acting upon regular expressions.
|
| > Fresh take on the modal editing paradigm.
|
| I wonder if the author has ever heard of vis[0] which imho
| fulfills far better each one of those premises
|
| [0] https://github.com/martanne/vis
| gilcot wrote:
| Note that all of those (but with some limitations on multiple
| selections via RE) are available in Ex/Vi and Ed previously.
|
| > I wonder if the author has ever heard of vis[0] which imho
| fulfills far better each one of those premises
|
| Same goes for Sam...
| lapinot wrote:
| > I wonder if the author has ever heard of vis[0]
|
| Yes.
|
| https://github.com/martanne/vis/wiki/Differences-from-Kakoun...
|
| https://github.com/mawww/kakoune/wiki#onboarding
|
| > which imho fulfills far better each one of those premises
|
| Not very motivated for such a harsh critic..
| BaculumMeumEst wrote:
| i remember him mentioning that he had at least heard of it in a
| post from years ago.
|
| vis is cool but its structural regular expressions are much
| less easier to use since kakoune's give you feedback in real
| time. it is nice that vis actually has a lua API though.
| [deleted]
| dang wrote:
| Related. Others?
|
| _Even more hindsight on Vim, Helix and Kakoune_ -
| https://news.ycombinator.com/item?id=36427267 - June 2023 (115
| comments)
|
| _Why Kakoune - The quest for a better code editor (2016)_ -
| https://news.ycombinator.com/item?id=36424256 - June 2023 (89
| comments)
|
| _More hindsight on Vim, helix and kakoune_ -
| https://news.ycombinator.com/item?id=36066347 - May 2023 (1
| comment)
|
| _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)
| alexvitkov wrote:
| Is it worth learning Dvorak? Sure it makes sense on paper, I see
| the rationale behind it, but I've already been typing on QWERTY
| all my life and I'm pretty fast at it. Kakoune is the same thing
| for me - the things changed from Vim make sense, but I don't see
| it as good enough to offset the facts that:
|
| 1. Vim is muscle memory for a lot of us. Something that is so
| similar but not quite the same just fucks with my brain. I have
| an easier time using stock Emacs bindings than Kakoune, as my
| brain is not in Vim mode while using it.
|
| 2. VS Code, Fat Visual Studio, IntelliJ, Emacs, most IDEs/text
| editors, fuck even Compiler Explorer have Vim plugins that range
| in quality from acceptable to fantastic. You can get a fix for
| your vim needs even in a disgusting corporate Windows crackhouse
| environment.
|
| 3. If you're a purist, Vim itself has a great ecosystem, and can
| be reasonably used for a lot of tasks.
| darau1 wrote:
| This was exactly my thought process before switching to vim.
| sevensor wrote:
| Regarding (1), I used Vim for 19 years, and I had strong muscle
| memory. However, I found it took only about a week to get
| comfortable with Kakoune. Its multiple-selection-oriented
| editing just mapped really well onto how I was already using
| Vim, which is to say, making extensive use of visual mode and
| highlightsearch. I have met Vim purists who tell me this is
| missing the point of Vim. If so, all the more reason to make
| the switch. But if verb-motion works better for you than
| selection-verb, by all means continue using Vim; it's a great
| editor.
| colordrops wrote:
| I switched from a standard split ergo keyboard to a split
| orthographic with curved rows (Glove80 specifically). I'm still
| questioning my move. I was pretty damn fast with the standard
| split, and I'm still struggling with special characters on the
| Glove80. It feels like it's coming though, and at least it's
| fun. And perhaps it will reduce wrist and finger strain as I
| get older.
| commandersaki wrote:
| I have similar reasoning for not bothering to learn an FP
| language (I have dabbled though) and stick with imperative.
| Conscat wrote:
| I used Dvorak for awhile. It's okay, at least better than
| QWERTY. But it's super old, and keyboard layouts post-Colemak
| take advantage of rolling bigrams and trigrams, unlike Dvorak.
| I use Hands Down now.
| https://sites.google.com/alanreiser.com/handsdown
| bongobingo1 wrote:
| Its a funny thing. I swapped to Colemak, was definitely worth
| it. I am pretty sure there are better layouts, but also I'm
| so wary of falling into a sort of productivity-tool/gear-
| acquisition-syndrome where I can never settle on one that is
| "perfect".
|
| Swapping wasn't _hard_ , but it sure wasn't easy. Did you
| find going from B -> C (-> D?) easier than A -> B?
| lawn wrote:
| > Swapping wasn't hard, but it sure wasn't easy. Did you
| find going from B -> C (-> D?) easier than A -> B?
|
| For me, going from B -> C and C -> D (and then a long
| period of tweaking) was significantly easier than from A ->
| B.
| legohead wrote:
| Every other keyboard you may need to use; for family, work,
| friends, is QWERTY. That is enough reason for me to stick with
| the norm. I already type 120wpm, which is only useful for a
| speed typing test. I never code, or even write documentation,
| at 120wpm.
| jwells89 wrote:
| The theories behind newer layouts are solid I think, but I've
| avoided adopting them simply because if I don't regularly use
| QWERTY, my capacity for using machines other than my own
| suddenly takes a steep nosedive.
|
| My preferred layout is HHKB/Tsangan, a minor variant on QWERTY
| that replaces Caps Lock with Control, moves Esc to the number
| row, collapses F-keys into a number row layer, and moves
| Backspace down where backslash/pipe are and even with that
| standard keyboards can be frustrating (you don't realize how
| hard standard Esc and Backspace positions are to reach until
| you've tried this layout). I can't imagine what it'd be like if
| I were using DVORAK or something.
| rbits wrote:
| The second point is the biggest reason why I haven't switch to
| Kakoune or Helix yet. I've used vim for just over a year now
| and I'm still annoyed at how unintuitive some things are, I
| still can't remember half of the shortcuts. I tried out Helix
| and it's great! I especially love the multiple cursors.
|
| But I never use vim by itself, I use it in other apps. And
| there's a perfectly good Helix plugin for VSCode, but I also
| use vim mode in Obsidian (since I'm constantly switching back
| and forth between Obsidian and VSCode) and there is currently
| no plugin for anything else. I need my code editor and my note
| editor to have the same controls, otherwise my brain gets
| confused.
|
| Once a Helix or Kakoune plugin is created for Obsidian, I am
| switching straight away.
| mbork_pl wrote:
| > I need my code editor and my note editor to have the same
| controls, otherwise my brain gets confused.
|
| I fully agree - but why use two separate editors, then? (Full
| disclosure - I'm a long-time Emacs user, making most of my
| notes in Org-mode.)
| petr25102018 wrote:
| > Helix plugin for VSCode
|
| Which one?
| turboponyy wrote:
| Vi-style binds are moderately unintuitive, but they are the
| lingua franca of keybind languages, and knowing them has
| value in and of itself. I'm glad I learned vi-style binds
| just before Kakoune and Helix gained popularity, as I use
| them in dozens of contexts other than my text editor.
| gilcot wrote:
| > Vi-style binds are moderately unintuitive,
|
| Oh... For my part, other binds are weird and less ergonomic
| from far. I'm vey used to vi-style: I mostly work in text
| mode (no GUI, no mouse) and I like to talk to my editor
| what I want...
| jodrellblank wrote:
| Dendron is an Obsidian-alike plugin for VS Code.
|
| https://www.dendron.so/
| eviks wrote:
| Roughly how many shortcuts in other apps like Obsidian would
| you need to rebind to avoid the annoyance?
| zoogeny wrote:
| I have at various times in my life tried to use vim or emacs.
| Each time I get comfortable enough in them to appreciate them
| but I run into the same problem every single time: it is
| annoying to switch back out of them.
|
| I had an acquaintance that told how he had spent years
| investing in Dvorak. He came back to QWERTY because he got a
| job where he had to jump onto others computers on occasion. The
| friction he felt fighting against his muscle memory was more
| annoying than any benefit he got from the supposed better
| Dvorak layout.
|
| I now use VSCode for 90% of my stuff and I use vim whenever I
| ssh into boxes or if I really need a quick edit from the CLI.
| But I keep vim totally stock, not a single thing in my dot
| file. There are aspects of my previous highly-customized and
| personalized vim setup that I miss - but I am free from the
| frustration of them not being there.
|
| As I get older, freedom from frustration has become more
| important than the marginal improvements of customization for
| efficiency.
| dingnuts wrote:
| Funny, you use VSCode for the same reason I use Emacs -- so I
| can keep vim totally stock, so I'll retain the muscle memory
| / not be shocked on other systems, and so that it remains
| completely reliable and fast on my own.
|
| I'm incredibly skeptical, however, that VSCode has as-good of
| a vim emulation layer as evil-mode. Evil-mode is just
| fantastic. Customized Emacs w/ evil-mode gives me everything
| I'd get from a fancy IDE, and keeps my vim muscle memory
| intact for those times when I am using regular vim.
|
| This has been my pattern for a decade and it's glorious.
| GLORIOUS, I tell you! Few things give me joy in computing
| like the balance in the Force that I've managed to strike
| between Emacs and vim
| imiric wrote:
| For sure, Emacs with evil-mode is the best of both worlds:
| deep customization and sane configuration language of
| Emacs, with the arguably superior modal interface of Vim.
|
| Using mnemonic key bindings is much friendlier than dozens
| of random key combinations. There's a popular key-chord
| package[1] that minimizes this discomfort, but without
| editing modes, users need to be concerned with the chords
| clashing with their actual text, which is absurd. Modes
| address this issue gracefully.
|
| I still use some basic combinations like M-x, but I would
| be completely lost in Emacs if it weren't for evil-mode. <3
|
| The thing with modal UIs is that you want to use them
| everywhere. So I also enable vi-mode in my shells, and in
| any application that uses readline.
|
| [1]: https://www.emacswiki.org/emacs/KeyChord
| SKWR-PLS wrote:
| This is pretty close to how steno
| [https://www.openstenoproject.org/] works in practice and
| worth learning IMO if you are going to go this far. In
| fact I have a few emacs-specific chords, but not as many
| as you might think. The whole experience is a bit like if
| emacs is now your keyboard, so it happens to go great
| with emacs.
|
| [1]
| lawn wrote:
| Honestly, configuring Neovim with Lua felt more sane than
| elisp for me.
| elcritch wrote:
| There's two VSCode vim plugins, one a native one and the
| other actually uses neovim. They're both pretty good. The
| main downside is that VSCode plugin can take some time to
| startup.
|
| I use the native one as it's a little less "pure" about VIM
| and integrates better with VSCode things. Overall it's less
| evil than evil. ;)
| imiric wrote:
| I never understood the logic of not using something because
| it's difficult to switch away from it.
|
| If I need to program, I just copy my Emacs configuration to
| that machine. I have never encountered a situation where I'm
| forced to use stock Emacs, or someone else's Emacs
| configuration. If I need to make a quick edit from the CLI,
| using plain Vim is fine, but I feel more "at home" with my
| own tweaks. None of these things are hurdles that would make
| me settle for an editor that someone else has preconfigured
| for me.
|
| At the end of the day, this will depend on how important you
| find customizing your working environment to your liking. If
| you're fine with someone else making that decision for you,
| you'd probably find the stock configuration, or someone
| else's configuration, acceptable. If OTOH you have strong
| opinions about the way you want to use your editor, then the
| time and effort invested in configuring it and managing that
| configuration is not an issue.
|
| This goes beyond just text editors, and applies to computing
| in general. Some people are fine with using stock software as
| it comes from the manufacturer. Most software, in fact, is
| not deeply configurable. Apple devices and software are
| wildly popular despite lacking configuration. But the reason
| we choose operating systems like Linux, and text editors like
| Vim and Emacs is precisely because they give us the freedom
| to use our computers in the way we want to use them, not as
| someone else thinks we ought to.
| lawn wrote:
| If you do it, do it for comfort not speed.
|
| And also consider Colemak-DH over Dvorak.
|
| If you're worried about having to relearn Vim commands, it's
| not a big deal. You're not remembering the key positions but
| the mnemonics, so "dta" means "delete to a" not some key
| positions. You'll be fine.
| unshavedyak wrote:
| > If you're worried about having to relearn Vim commands,
| it's not a big deal. You're not remembering the key positions
| but the mnemonics, so "dta" means "delete to a" not some key
| positions. You'll be fine.
|
| Oh man, this was so difficult for me with a split ortho
| keyboard. I realized that most of my bindings now i don't
| actually "know". It's 100% muscle memory.
|
| I had to keep a keyboard handy to "do the thing i want on the
| unplugged keyboard" to see what the bind was. Kinda mind
| blowing to me hah.
| lawn wrote:
| That's interesting. I had zero problems moving from a
| regular qwerty layout to a split 34 key keyboard.
|
| I did switch to a BEAKL layout, and then to my own layout.
|
| So maybe we learn things differently?
| em-bee wrote:
| sure, but that's the same argument against any form of
| incompatible change.
|
| it was used against the fish shell for example. yet eventually
| it started getting acceptance. the same may happen with
| kakoune. i tried using it myself. i wasn't so much bothered by
| the changes. i had different issues. i got burned by kakoune
| overwriting a file without warning me. vim would not have done
| that. and i couldn't get over the fact that kak means shit in
| some languages. it will take some more effort to overcome that
| and give it another try.
| [deleted]
| thomastjeffery wrote:
| It's worth getting a physical keyboard that's actually
| ergonomic, like a Keyboardio, ergodox, dactyl, or whatever.
| Just pick the one you are most excited about using.
|
| It's significantly less valuable, but still worth learning an
| alternative keyboard layout, though Dvorak specifically isn't
| nearly as good as modern alternative like Colemak or Workman.
|
| Vim is incredible for every reason _except_ its keybinds.
| Technically, you can remap them, but that quickly devolves into
| dependency hell... learning to type using the Workman layout is
| why I 'm an Emacs user today. One of these days I'll get around
| to making a truly _configurable_ modular editor...that will
| most likely be an Emacs config.
| Nadya wrote:
| I come out of the woodworks every now and again whenever I see
| Dvorak mentioned in any context. I really despise its
| popularity as an alternative keyboard layout because I feel it
| wasted a good year of my life.
|
| 1) Few people will have benefit of learning Dvorak. What
| benefits they see comes from learning how to properly touch
| type by forcefully breaking bad habits with their original
| (usually QWERTY) keyboard layout.
|
| 2) Switch to Colemak or any more modern layout that takes
| advantage of bigrams/trigrams better. Colemak is genuinely
| superior to QWERTY beyond just learning to touch type.
|
| I used to type 170~ WPM on QWERTY. Sustained. By all means an
| accomplished typist. I learned Dvorak well enough to get back
| up to 120~ WPM but saw no real benefits of using it: I already
| knew how to touch type. But QWERTY was causing my hands to
| cramp up over time and so I was on the search for improving
| that. I gave Colemak a try and it was a great relief. I only
| type 150~ WPM on Colemak after some years of using it but the
| lack of pain from typing for long periods of time is worth the
| small hit to my typing speed.
|
| Almost every single person I see who touts benefits of learning
| Dvorak was typing <60WPM in QWERTY and did not know how to
| properly touch type. The benefits they see weren't from using
| Dvorak: it was from finally learning how to touch type
| properly.
|
| Apologies as I know Dvorak wasn't really the focus of your post
| here. But in an attempt to perhaps make it still relevant:
| change every now and then is good. It can break you out of bad
| habits you didn't know you had learned and sometimes open you
| up to new ways of accomplishing something. As other replies
| have mentioned - I'm a big fan of Helix and gave up Neovim for
| it.
| tjoff wrote:
| > _What benefits they see comes from learning how to properly
| touch type by forcefully breaking bad habits with their
| original (usually QWERTY) keyboard layout._
|
| With that I fully agree, but then again - in my mind that
| exactly is the value proposition of any non-QWERTY-layout.
|
| I also agree that ergonomics is more important than peek
| throughput.
|
| But you neglect the cost. The cost of ruining shortcuts in
| many applications and/or complex OS settings just to be able
| to type. There are workarounds and solutions for most but I
| haven't been convinced it is a net gain.
|
| So in my opinion, stay and invest in QWERTY instead.
| Regarding ergonomics use a split ortholinear keyboard. I am
| in doubt any layout will be as liberating as that and orders
| of magnitude less investment in time.
|
| Everytime I use or think of a staggered keyboard I'm amazed
| at the design. Put your right hand over the right hand of the
| keyboard as if to type, the columns kind of naturally go with
| your fingers - not bad at all really. Then do the same with
| your left hand and it is just a clusterfuck.
|
| Though I do have to acknowledge two things, you can of course
| use and benefit from an alternative layout on an ortholinear
| keyboard as well. And the cost of only feeling at home on a
| bespoke keyboard (not that it is different enough for you to
| not be able to use a normal keyboard) isn't negligible
| depending on your situation either.
| self_awareness wrote:
| One even bigger problem with Dvorak isn't the speed, which is
| actually very hard (next to improssible) to objectively
| measure; it's that you lose the ability to write on somebody
| else's computer, or phone, depending on where you're using
| Dvorak.
| imiric wrote:
| > I used to type 170~ WPM on QWERTY.
|
| That's an absurd speed.
|
| I can touch type on QWERTY, and last I measured I hovered at
| around 100 WPM on my best efforts. But TBH typing speed is
| really not something I'm concerned about. When I'm
| programming, accuracy is more important than speed, and I
| spend much more time thinking than actually typing. And when
| I'm writing prose, I also make pauses to rethink what I'm
| writing, and go back and forth, refining the text to match my
| thoughts. So even if I typed much faster, my overall speed of
| communication or programming wouldn't improve.
|
| I also haven't had any discomfort after decades of typing on
| QWERTY keyboards. I find it hard to believe that a different
| layout would reduce discomfort more than using an ergonomic
| keyboard, with proper wrist support and posture.
| thomastjeffery wrote:
| Typing on a traditional keyboard using the Workman layout
| is - in my experience - significantly more comfortable.
|
| Typing on an actually ergonomic keyboard (currently a
| Keyboardio Model01) is a _much_ more significant comfort
| difference.
|
| Both together scratches an itch that I recognize not
| everyone has, but if you do have that itch, scratching it
| feels damn good.
| euiq wrote:
| I am intensively envious of people who type this fast; I get
| up to 100 words per minute on a good day. Time to get a new
| pair of hands?
| F3nd0 wrote:
| I understand that Dvorak hasn't been great for you, but I
| don't think it's fair to attribute all of its success and
| merits to touch typing. The distribution of keys is obviously
| more optimal than than of QWERTY, and even if your analysis
| holds true for some Dvorak typists, I doubt it does for a
| majority (or even a significant portion) of them.
|
| Speaking from my own personal experience, I learned to touch
| type (properly) on QWERTY first, but after a while I switched
| to Colemak. After yet another while, I switched to Dvorak,
| and have been using it for several years now. For me, Dvorak
| has been slightly more comfortable than Colemak (which, in
| turn, was much more comfortable than QWERTY); though I have
| to admit I've never experienced significant pain or cramps
| just from typing. In any case, I find both layouts to be a
| great improvement over QWERTY, and certainly not only because
| of touch typing.
| Nadya wrote:
| The primary difference is rolling vs alternating (as
| someone else mentioned) and slight left vs right hand
| biases (I don't think anyone brought this up yet) and there
| is some definitely enough room for preference of one over
| the other there. I prefer rolling over alternating and I'm
| left-hand dominant. For finger alternation I'd recommend
| any of the CarpalX layouts (Qgmlwb specifically). If I knew
| about CarpalX before learning Colemak I probably would have
| learned it instead but I also don't want to relearn typing
| for a 4th time.
|
| There's always a handful of exceptions to every rule but by
| and large from my experiences in the altkey layout
| communities the people who touted Dvorak the loudest
| largely didn't know how to type properly before learning
| Dvorak and it was their first alternative layout learned.
| So it's colored my view a bit.
|
| I have regularly typed for >8 hours/day - nearly every day
| - since age 8. The hand pains didn't really start until I
| was in my 20's.
| zimbatm wrote:
| Especially when programming. A lot of key shortcuts are
| specifically designed for QWERTY. And if you believe that the
| keyboard should be re-arranged to better fit the language
| then shouldn't a programming layout have more easily
| reachable symbol characters? (and varying depending on the
| language).
| tmtvl wrote:
| Eh, I'd say it kinda depends, Colemak focuses more on rolls
| while Dvorak focuses more on alternating between hands.
| Though I think that Workman is a superior alternative to
| Colemak when it comes to ergonomic rolls.
|
| Xah Lee wrote an analysis on why he believes Dvorak is better
| than Colemak: <http://xahlee.info/kbd/dvorak_vs_colemak.html>
| and he brings up the frequency of the "th" digram, which on
| Colemak is a bit of an issue due to the finger travel.
| vaylian wrote:
| Take a look at https://helix-editor.com/. It is basically a
| continuation of the ideas behind Kakoune but with a primary
| focus on modern day programming with a language-server. I use
| it for most of my programming today, because the language
| server support out of the box is just so much better than
| anything I managed do with Neovim.
| phowat wrote:
| This project looks amazing, thanks for sharing.
| Unfortunately, I'm not willing to give up Copilot for a
| better editor. But I'll keep this on my radar.
| notnmeyer wrote:
| yeah, the lack of a plugin ecosystem and consequently,
| copilot support, is the hardest pill to swallow with Helix
| right now. that said, its an amazing editor. excluding the
| plugin stuff, its batteries-included and is so refreshing
| to not have to mess with configuration files just to get it
| to a useable state.
| TylerE wrote:
| Maybe it's just me, but a TUI-only editor is a non-
| starter for me, for a number of reasons, first being that
| my terminals are set up for maximum readability for
| shorter sessions, not eye comfort over hours.
| aae42 wrote:
| What about setting up a dedicated terminal for your
| editor? I think a GUI version is in the works, but that's
| probably what it will end up as.
|
| My editor stack has been Zellij, Helix and gitui as of
| late, and, there's still a few important things missing
| for me, but still working on it...
| haarts wrote:
| Same setup as me! I do miss out on the AI integrations
| (copilot etc), that I find a shame.
| TylerE wrote:
| I have other reasons... I a lot of searching across field
| and work in huge monolith with tens of thousand of files.
| wredue wrote:
| ThePrimeAgen uses Dvorak and for raw typing speed has said it's
| probably not worth. Fast typists on qwerty and Dvorak seem to
| be in line.
|
| Stress on the good ol wrists and digits though? Not really
| sure. If there is a reason to switch, it'd be based on that.
| kaba0 wrote:
| I think quality of keyboard probably plays an order of
| magnitude bigger difference.
| Hammershaft wrote:
| I'm currently using Kak for system configuration, limited shell
| scripting, and soon, learning Zig. (I use evil emacs for all of
| my heavy duty coding (lisp mostly))
|
| Kak is such an elegant form of modal editing compared to Vim &
| Emacs. Selection first paired with feedback & suggestions gives
| Kak a discoverability emacs & vim simply do not approach. This
| also means you can pick up and learn Kak in a fraction of the
| time you'll learn the others. I recommend finding or creating a
| purpose for Kak if you're interested in the tools you use and how
| they can be made better.
| johnfn wrote:
| I'm not sure I understand what the big deal is with selection-
| first. If I want vim to be selection-first, I just press v.
| It's just one keystroke!
| r3trohack3r wrote:
| I've been using Kakoune as a daily driver for about 2 years now.
| It's an order of magnitude better than anything else I've tried
| (vim, neovim, vscode, atom, jetbrains, codeblocks, notepad++,
| etc).
|
| Especially once you:
|
| * enable LSP support
|
| * memorize the keybinding
|
| * get comfortable with the kakoune scripting language
|
| The keybindings were a lot easier to memorize than VIM's because
| of how consistent they are. And they're a lot easier to
| "experiment" with when your memory is fuzzy because you get
| realtime visual feedback on what your key combinations are
| building up in memory before it executes.
|
| It's fast, unbelievably fast - faster than I type no matter what
| I'm doing. I never wait for anything unless I'm shelling out to
| some "modern" build/lint/style tool with a script.
|
| It works out of the box with tiled window managers (:new opens a
| new terminal, `kak -c lets you open a new window into an existing
| editor session, etc.).
|
| I can seamlessly move between the system clipboard and buffers
| using `xclip`, which is the same pattern that lets me seamlessly
| move between _any unix tool_ and a buffer. I can type `!tree` and
| get the directory listing for a README.
|
| I can `%s [][]bytes<ret>di[]Image` to replace all arrays of
| images with an explicit type. With LSP support, I can highlight
| all _references_ the the currently highlighted
| variable/object/w.e., then select the entire line each one is on
| and delete it in like 4 keystrokes.
|
| It gives realtime feedback as I type commands so I can see what
| I'm selecting in a buffer.
|
| Autocomplete is aware of everything from LSP and _every open
| buffer_, so you can open buffers full of context you'd like
| autocomplete to have access to even if LSP isn't able to infer
| it.
|
| I can wire up custom commands for each file type using the
| scripting language in minutes, not hours, to do things like
| automatically run the language's auto formatter.
|
| With LSP enabled, I can `gd` on any variable/object/function/w.e.
| and _immediately_ find myself looking at where it was defined.
| Even if that definition is the go standard library, Node core,
| some dependency down inside my node_modules or vendor directory,
| w.e.
|
| With LSP enabled, I get the entire MDN library fact-checking my
| method signatures and helping me with autocomplete _in realtime_
| as I type.
|
| Some tips for people wanting to use kakoune:
|
| Add this bash script to your PATH as `k`, it lets you open a new
| window into the current editing session from any terminal - so
| you can `cd` around the filesystem to look for files of interest
| and then open them in another terminal's editing session top copy
| stuff over and make autocomplete aware of its contents:
| https://gist.github.com/retrohacker/8920d056f4938e8dd263adac...
|
| Take the contents of `:doc` and put it all into something like
| Anki (or just make flash cards for yourself). Learning the
| keybindings by heart is a small investment that will pay massive
| dividends.
|
| Integrate LSP and take a moment to learn the different commands.
| I can't stress this enough.
|
| Wait until about 6 months in to bother trying to learn the
| scripting language. The scripting language is pretty much what
| you've been using the entire time, you just write it down in a
| config file instead of typing it into a live session. The
| scripting language docs don't make any sense unless you already
| know kakoune, it's much easier to understand once you have a
| better feel for how kakoune works.
|
| Once you learn the scripting language and have a good feeling for
| the default keystrokes, you can start mapping a bunch of your
| common workflows (`!` and `:` commands, buffers, etc) to unused
| keys, or keys you have no use for.
|
| Here is my kakrc for reference, but keep in mind I change this
| fairly often as my workflows change across code bases:
| https://gist.github.com/retrohacker/cfc72d59dbcb14adb5009a26...
|
| I think the hex to HSLA is a pretty good example of what's
| possible with kakoune. I whipped that up in maybe 10 minutes with
| a go binary on my path and that hook. I'm in a code base where I
| was constantly converting from a color design guide defined in
| HEX to the code base's standard of hsla. Now I just copy into the
| editor and it auto-fixes it.
___________________________________________________________________
(page generated 2023-09-21 23:02 UTC)