Function signature-based CLI approach reminds me of my favorite (at least in concept) Python CLI library, typer. However in practice argparse is usually good enough and adding an external dependency does not always seem worth it for better ergonomics, reflecting some of kbknapp’s arguments above. On top of that, there are a few differences on the front end, like list-valued options where -l a b c -- <positional_arg> is valid with argparse but typer/click require using -l a -l b -l c <positional_arg>.
I had run across typer before, but at the time I was spending my mental energy learning about fastapi, and I forgot to come back to it. That’s really nice. I hope I remember it next time I want a quick cli gadget. I usually use click, and I always find myself needing to re-learn those decorators. Typer looks like what I wished click would grow into.
AFAICT, plac was the original gangsta of all this “infer from the signature” jazz argh was fast on its heels, though. Earlier on (for like a decade), before Guido had blessed the token region in the function signature for type hints in Py3, you could instead stick a string there next to parameters “repurposing” the syntax for per-parameter documentation. This was “easier to remember” enough that the plac author himself stopped using it when it became unavailable.
In contrast, the Nim cligen also mentioned above, just takes a little help list like dispatch myCmd, help={"param1": "what does param1 do", ..}. While unfortunately lexically remote from its point of declaration (since Nim does not have a prevailing convention of doc comments near decls in parameter lists), this does at least have the charm of not being hard to remember.
This is one of the areas the web UI of (some) git forges are good, in my experience. For instance Azure DevOps allows you to click on a file in the PR diff view and that takes you to the full file view that also shows the diff (whether you want it split or unified). It is one of the things I miss on GitHub, where the best approximation seems to be to spam the arrows to expand the diff view up/down.
I currently use Streamlit for a quick-and-dirty web interface for a toy project, hosted on Streamlit Cloud. It took me about an hour to go from a CLI to a mostly-working web interface and only a few minutes to host it on Streamlit Cloud so that was great.
That being said the remarks at the “Why?” section resonates with me, now that I added more inter-dependent widgets in my Streamlit app. I think I’ll miss the easy hosting with NiceGUI: FastAPI docs mention Deta as an option but they don’t even seem to support Python 3.10 yet, and they seem to be in the process of a revamp. Does anyone have any experience with Deta Cloud/Spaces or a similar alternative?
(As an aside, Streamlit cloud also hasn’t been the most reliable, with the app being stuck on blank screens occasionally on different browsers and an “outage” that randomly broke the website for some people that was discussed in their Discourse which seems to be fixed [but I haven’t come across any official announcement].)
If anyone is wondering about what the coverage of the implementation is like I was, this seems to be the list: https://rustpython.github.io/pages/whats-left (and a more comprehensive list that was updated recently from regression test coverage?). Although I see some pretty popular modules in there it is still difficult to tell how much impact the lack of support would have on the average Python project.
I could recommend utilizing the thumb keys more and offloading work from pinkies. For instance, Shift is a very heavily used modifier and I really like having it on my most accessible thumb key. If you don’t want to lose an existing key, mod/layer taps are a very useful feature (although sometimes you need to tweak it to get it working to your liking). I am comfortably using a 36-key keyboard thanks to these features + combos (aka chording).
I’m looking at using autoshift to offload most of my shift use. I started with it enabled, but it was really messing me up so I disabled it. I will probably end up using it though.
I do have a gergoplex kit coming in the mail soon. Once it gets in and I solder on all the switches I will write about it and how I adapted my config to it.
Autoshift sounds very useful but I admit I haven’t given it a proper shot. When I tried it required me to change my workflow for Vim/Vimium since I tend to hold down keys for scrolling (bad habit).
Good luck with your Gergoplex, it’s a fun experience optimizing your workflow for 36 keys! Also it is not on QMK master yet, but I have been using this branch successfully.
Pinky is the weakest finger, so requiring holding it down is less comfortable. You also have to move off the home key positions to reach the outermost column. In contrast, thumbs are pretty strong and you don’t have to contort your hand when holding down a thumb then pressing other alphas.
I do appreciate thumbs keys, previously on an ergodox and now on a Planck. I can’t recommend the SZA ”EZ” products enough.
That said, the thumb is not really at ease on this keyboard. I find that while it’s strong, the movement required to tap the keys is not the most natural. That being pinching, in an plane orthogonal to the other fingers. As a consequence, I find that turning the keycaps around (with the slope facing the user) helps a bit.
It’s great at holding modifiers though. My setup is such that each thumb has two tap/hold keys lower(esc), os(space), shift(return) and compose(BS). I often press two modifiers with the same thumb.
I also kept the lateral and symmetrical control and shift, just for the occasional ZZ, etc.
The moonlander has a tilted thumb cluster, that should help with that. However those keyboards are so big that holding a key with the thumb makes it problematic to reach the distant keys. In the end, I prefer the Planck/preonic for factor, even with my big hands.
I feel like this is less keys that are tapped on their own and more an issue for modifier keys; it can cause strain on some people’s hands to reach a far key while the pinky is holding down shift/alt/super/etc.
The biggest improvement I made in my prompt in years is to only display the hostname when I am SSH’ed. After all I know what machine I am on physically, so it is just extra noise.
That was an interesting read. The author went deep down the rabbit hole, but took a different approach than most compared to what I have seen in r/ErgoMechKeyboards or various Discord channels. My experience is that people tend to gravitate towards either (a) very customized, keywell keyboards like the Dactyl Manuform (similar to the Kinesis models), or (b) fewer keys so that there is less hand movement, but usually 3 rows and 5 or 6 columns, like the Corne, GergoPlex or Kyria. Not to mention that Ergodox specifically is constrained by some legacy design decisions and is not necessarily very ergonomic, especially for people with normal sized hands.
It is also worth mentioning that there is a separate trend of going lower profile with Kailh Choc switches so that your wrists are more comfortable and you can perform key combos with multiple keys easier.
Of course there are many people who work on optimizing their keyboard layout, but people tend to converge to alternatives like Colemak DHm, Workman or RSTHD layouts, rather than coming up with their very customized version.
Macropads are a good introduction to the deep hole of building your own keyboards, most of which only require basic soldering. For anyone else interested, there are many alternatives through different vendors, with different availability (which is unfortunately usual for this hobby where stock comes and goes, some are only available through group buys etc.):
I really like the concept of Kakoune, tried it a couple of times and inverting the movement to action order is a great UX improvement. But unfortunately my muscle memory in vi is keeping me there, the differences is simply slowing me down too much. I would however love to see someone to “steal” Kakoune style editing in a vim extension, visual mode is the closest we have, which I do use quite a bit but it’s not quite the same.
The upside is that such an extension could be used on an opt in basis, e.g. by toggling it via a :ToggleKak or as an additional mode which can be entered from normal mode. This would allow me to instantly switch back to normal vi-mode thus making me able to get used to it gradually.
Additionally I was thinking an extension that keep more original vim movements instead of keeping some and changing others. Word is the same in kak but for instance foregoing g and GG for instance is a massive hassle, I don’t recall on top of my head what more was missing but there was quite a few changes. These changes probably makes sense if you start from a blank slate and thus makes sense for a new editor but as an extension to vi/m I’d rather see adherence to the old learned movement words.
Edit:
Some things that I notice missing/changed at once when starting kak again and just trying to navigate a little bit in the project I’m working on right now:
Folding, zc/zo
Set line numbers, :set nu
Go to line, :n where n is line number
gcc/cs are popular plugins for comment and change surrounding, these are popular enough to be ported to vi-mode in other editors like vscode.
At this point I’m going back to vi because it’s unfortunately slowing me down to much to get real work done.
Now I still love what kak is doing and if I weren’t already a vim user a lot of the things probably make a lot more sense.
I found that the bindings that got changed from Vim was mostly an improvement in consistency, whereas original Vim bindings are constrained by their legacy. For instance in Kakoune shifted version of keys “extend” your current selection rather than move it. Thus, G is just g (which enters “goto” mode that includes g for buffer begin, j for buffer end etc.) that extends the selection rather than moving it, which is why you need to use gj instead of G to go to the buffer end.
Other than folding (which is not currently possible) your other missing features are actually available right now, so if you decide to give it a go again here are some pointers:
Set line numbers, :set nu
This is available as a highlighter, documented in :doc highlighters and the wiki page
Go to line, :n where n is line number
This is available with <n>g, from :doc keys
gcc/cs are popular plugins for comment and change surrounding, these are popular enough to be ported to vi-mode in other editors like vscode.
This is built-in with :comment-line and :comment-block commands, but not mapped to a key by default
I can’t blame someone much for not being able to discover some features – while in-editor help with the clippy and reference documentation with :doc is pretty great, it doesn’t have a good “user manual” like Vim that the user can discover features through. The wiki also helps but is not very well organized. TRAMPOLINE is a decent vimtutor replacement, but hard to find unless you know it exists.
Similarly for me, kak just simply isn’t available as ubiquitously as vi(m). I fear relearning the muscle memory would be a detriment in the long run as I would still likely need to switch back to vi(m) fairly frequently
What might be left out about how common place vi(m) is the fact that there are vi(m) modes for A LOT of things, I’m talking editors like VSCode, IDE’s like JetBrains suite, Visual Studio, emacs evil, etc. but most importantly all major browsers (vimari/vimium/vimpinator/pentadactly/qtBrowser/w3m/etc), window managers (ultimate macOS for one), tmux, shells, scripting via s(ed), and more. Wherever these will diverge from kakoune there will be friction in daily usage.
Again this isn’t criticism to kakoune just a note on how ubiquitously available the vi(m) keybinding set really is.
Additionally to that I’ve worked with industrial control systems often being quite literary air gapped (not uncommonly located in rural places without internet connection) running some flavour of BSD/Linux, vi is pretty much always available for some quick adhoc configuration at a customer site, anything else, not so much.
Have any sources on the neovim backend? I use neovim as my daily editor and was unimpressed by VSCodes vim plugin about ~1 year ago, but using neovim as a backend might address my concerns.
I’ve tried OniVim2, as I purchased a license way back when it was fairly cheap. Their current builds seem very promising.
What distro are you using that doesn’t have a Kakoune package available? About a dozen are supported, it’s surprising to hear that the editor isn’t widely available.
I can see a package for Alpine, I’ve installed it myself in Docker containers.
In any case, it’s true that muscle memory is a big obstacle when trying to use one or the other. But when you switch over to Kakoune, it’s harder in my experience to go back to Vi bindings (for example when there’s absolutely nothing else installed on a random system).
The Alpine package is on testing/edge, which isn’t considered stable. I already intentionally stick to stock vi(m) configurations as much as possible to alleviate muscle memory issues, switching seems like a step backwards to me despite the overall UI/UX language being better.
Function signature-based CLI approach reminds me of my favorite (at least in concept) Python CLI library, typer. However in practice
argparseis usually good enough and adding an external dependency does not always seem worth it for better ergonomics, reflecting some of kbknapp’s arguments above. On top of that, there are a few differences on the front end, like list-valued options where-l a b c -- <positional_arg>is valid withargparsebuttyper/clickrequire using-l a -l b -l c <positional_arg>.I had run across typer before, but at the time I was spending my mental energy learning about fastapi, and I forgot to come back to it. That’s really nice. I hope I remember it next time I want a quick cli gadget. I usually use click, and I always find myself needing to re-learn those decorators. Typer looks like what I wished click would grow into.
Thanks for mentioning that!
AFAICT, plac was the original gangsta of all this “infer from the signature” jazz argh was fast on its heels, though. Earlier on (for like a decade), before Guido had blessed the token region in the function signature for type hints in Py3, you could instead stick a string there next to parameters “repurposing” the syntax for per-parameter documentation. This was “easier to remember” enough that the plac author himself stopped using it when it became unavailable.
In contrast, the Nim
cligenalso mentioned above, just takes a little help list likedispatch myCmd, help={"param1": "what does param1 do", ..}. While unfortunately lexically remote from its point of declaration (since Nim does not have a prevailing convention of doc comments near decls in parameter lists), this does at least have the charm of not being hard to remember.This is one of the areas the web UI of (some) git forges are good, in my experience. For instance Azure DevOps allows you to click on a file in the PR diff view and that takes you to the full file view that also shows the diff (whether you want it split or unified). It is one of the things I miss on GitHub, where the best approximation seems to be to spam the arrows to expand the diff view up/down.
There are people doing really crazy things with awk, like this one: https://github.com/patsie75/awk-demo
I currently use Streamlit for a quick-and-dirty web interface for a toy project, hosted on Streamlit Cloud. It took me about an hour to go from a CLI to a mostly-working web interface and only a few minutes to host it on Streamlit Cloud so that was great.
That being said the remarks at the “Why?” section resonates with me, now that I added more inter-dependent widgets in my Streamlit app. I think I’ll miss the easy hosting with NiceGUI: FastAPI docs mention Deta as an option but they don’t even seem to support Python 3.10 yet, and they seem to be in the process of a revamp. Does anyone have any experience with Deta Cloud/Spaces or a similar alternative?
(As an aside, Streamlit cloud also hasn’t been the most reliable, with the app being stuck on blank screens occasionally on different browsers and an “outage” that randomly broke the website for some people that was discussed in their Discourse which seems to be fixed [but I haven’t come across any official announcement].)
If anyone is wondering about what the coverage of the implementation is like I was, this seems to be the list: https://rustpython.github.io/pages/whats-left (and a more comprehensive list that was updated recently from regression test coverage?). Although I see some pretty popular modules in there it is still difficult to tell how much impact the lack of support would have on the average Python project.
I could recommend utilizing the thumb keys more and offloading work from pinkies. For instance, Shift is a very heavily used modifier and I really like having it on my most accessible thumb key. If you don’t want to lose an existing key, mod/layer taps are a very useful feature (although sometimes you need to tweak it to get it working to your liking). I am comfortably using a 36-key keyboard thanks to these features + combos (aka chording).
I’m looking at using autoshift to offload most of my shift use. I started with it enabled, but it was really messing me up so I disabled it. I will probably end up using it though.
I do have a gergoplex kit coming in the mail soon. Once it gets in and I solder on all the switches I will write about it and how I adapted my config to it.
Autoshift sounds very useful but I admit I haven’t given it a proper shot. When I tried it required me to change my workflow for Vim/Vimium since I tend to hold down keys for scrolling (bad habit).
Good luck with your Gergoplex, it’s a fun experience optimizing your workflow for 36 keys! Also it is not on QMK master yet, but I have been using this branch successfully.
Interesting, why that? I have just mapped backspace to my left pinky (Capslock) on an Ergodox and it feels very natural to me.
Pinky is the weakest finger, so requiring holding it down is less comfortable. You also have to move off the home key positions to reach the outermost column. In contrast, thumbs are pretty strong and you don’t have to contort your hand when holding down a thumb then pressing other alphas.
There are even layouts which move the most frequent alpha, e.g.
Eto the thumb: https://precondition.github.io/pressing-e-with-the-thumbI do appreciate thumbs keys, previously on an ergodox and now on a Planck. I can’t recommend the SZA ”EZ” products enough.
That said, the thumb is not really at ease on this keyboard. I find that while it’s strong, the movement required to tap the keys is not the most natural. That being pinching, in an plane orthogonal to the other fingers. As a consequence, I find that turning the keycaps around (with the slope facing the user) helps a bit.
It’s great at holding modifiers though. My setup is such that each thumb has two tap/hold keys lower(esc), os(space), shift(return) and compose(BS). I often press two modifiers with the same thumb.
I also kept the lateral and symmetrical control and shift, just for the occasional ZZ, etc.
The moonlander has a tilted thumb cluster, that should help with that. However those keyboards are so big that holding a key with the thumb makes it problematic to reach the distant keys. In the end, I prefer the Planck/preonic for factor, even with my big hands.
I feel like this is less keys that are tapped on their own and more an issue for modifier keys; it can cause strain on some people’s hands to reach a far key while the pinky is holding down shift/alt/super/etc.
The biggest improvement I made in my prompt in years is to only display the hostname when I am SSH’ed. After all I know what machine I am on physically, so it is just extra noise.
Do you display the username by default?
I don’t, but I almost never use a different username so YMMV.
That was an interesting read. The author went deep down the rabbit hole, but took a different approach than most compared to what I have seen in r/ErgoMechKeyboards or various Discord channels. My experience is that people tend to gravitate towards either (a) very customized, keywell keyboards like the Dactyl Manuform (similar to the Kinesis models), or (b) fewer keys so that there is less hand movement, but usually 3 rows and 5 or 6 columns, like the Corne, GergoPlex or Kyria. Not to mention that Ergodox specifically is constrained by some legacy design decisions and is not necessarily very ergonomic, especially for people with normal sized hands.
It is also worth mentioning that there is a separate trend of going lower profile with Kailh Choc switches so that your wrists are more comfortable and you can perform key combos with multiple keys easier.
Of course there are many people who work on optimizing their keyboard layout, but people tend to converge to alternatives like Colemak DHm, Workman or RSTHD layouts, rather than coming up with their very customized version.
Macropads are a good introduction to the deep hole of building your own keyboards, most of which only require basic soldering. For anyone else interested, there are many alternatives through different vendors, with different availability (which is unfortunately usual for this hobby where stock comes and goes, some are only available through group buys etc.):
These are all programmed with QMK and some even support rotary encoders (knobs that can be used for adjusting volume, scrolling etc.)
I really like the concept of Kakoune, tried it a couple of times and inverting the movement to action order is a great UX improvement. But unfortunately my muscle memory in vi is keeping me there, the differences is simply slowing me down too much. I would however love to see someone to “steal” Kakoune style editing in a vim extension, visual mode is the closest we have, which I do use quite a bit but it’s not quite the same.
I might misunderstand you, but if muscle memory is what’s keeping you in vi, wouldn’t it also keep you from using such an extension?
The upside is that such an extension could be used on an opt in basis, e.g. by toggling it via a :ToggleKak or as an additional mode which can be entered from normal mode. This would allow me to instantly switch back to normal vi-mode thus making me able to get used to it gradually.
Additionally I was thinking an extension that keep more original vim movements instead of keeping some and changing others. Word is the same in kak but for instance foregoing g and GG for instance is a massive hassle, I don’t recall on top of my head what more was missing but there was quite a few changes. These changes probably makes sense if you start from a blank slate and thus makes sense for a new editor but as an extension to vi/m I’d rather see adherence to the old learned movement words.
Edit: Some things that I notice missing/changed at once when starting kak again and just trying to navigate a little bit in the project I’m working on right now:
Now I still love what kak is doing and if I weren’t already a vim user a lot of the things probably make a lot more sense.
I found that the bindings that got changed from Vim was mostly an improvement in consistency, whereas original Vim bindings are constrained by their legacy. For instance in Kakoune shifted version of keys “extend” your current selection rather than move it. Thus, G is just g (which enters “goto” mode that includes g for buffer begin, j for buffer end etc.) that extends the selection rather than moving it, which is why you need to use gj instead of G to go to the buffer end.
Other than folding (which is not currently possible) your other missing features are actually available right now, so if you decide to give it a go again here are some pointers:
This is available as a highlighter, documented in
:doc highlightersand the wiki pageThis is available with
<n>g, from:doc keysThis is built-in with
:comment-lineand:comment-blockcommands, but not mapped to a key by defaultI can’t blame someone much for not being able to discover some features – while in-editor help with the clippy and reference documentation with
:docis pretty great, it doesn’t have a good “user manual” like Vim that the user can discover features through. The wiki also helps but is not very well organized. TRAMPOLINE is a decent vimtutor replacement, but hard to find unless you know it exists.Thanks, that’s hugely helpful. Will for sure try out trampoline next time I give it a spin, I do love vimtutor.
Similarly for me, kak just simply isn’t available as ubiquitously as vi(m). I fear relearning the muscle memory would be a detriment in the long run as I would still likely need to switch back to vi(m) fairly frequently
What might be left out about how common place vi(m) is the fact that there are vi(m) modes for A LOT of things, I’m talking editors like VSCode, IDE’s like JetBrains suite, Visual Studio, emacs evil, etc. but most importantly all major browsers (vimari/vimium/vimpinator/pentadactly/qtBrowser/w3m/etc), window managers (ultimate macOS for one), tmux, shells, scripting via s(ed), and more. Wherever these will diverge from kakoune there will be friction in daily usage.
Again this isn’t criticism to kakoune just a note on how ubiquitously available the vi(m) keybinding set really is.
Additionally to that I’ve worked with industrial control systems often being quite literary air gapped (not uncommonly located in rural places without internet connection) running some flavour of BSD/Linux, vi is pretty much always available for some quick adhoc configuration at a customer site, anything else, not so much.
Yeah, this is also a factor for me, though less so as I have never been happy with a vim plugin/emulation layer.
The one in VSCode is surprisingly good if you bind it to a neovim backend. Onivim is also interseting but more expimental.
Have any sources on the neovim backend? I use neovim as my daily editor and was unimpressed by VSCodes vim plugin about ~1 year ago, but using neovim as a backend might address my concerns.
I’ve tried OniVim2, as I purchased a license way back when it was fairly cheap. Their current builds seem very promising.
What distro are you using that doesn’t have a Kakoune package available? About a dozen are supported, it’s surprising to hear that the editor isn’t widely available.
Telecom-deployed clusters of RHEL VM’s.
Can you not use this RHEL package?
First, no
el7build, second, getting it there would be problematic at best (in terms of file copying).Alpine Linux. I also occasionally deal with embedded ‘distros’ that don’t have a package manager .
I can see a package for Alpine, I’ve installed it myself in Docker containers.
In any case, it’s true that muscle memory is a big obstacle when trying to use one or the other. But when you switch over to Kakoune, it’s harder in my experience to go back to Vi bindings (for example when there’s absolutely nothing else installed on a random system).
When I use vim nowadays (and I install kakoune anywhere I need to edit anything), I am staying only with the very limited set of commads.
The Alpine package is on testing/edge, which isn’t considered stable. I already intentionally stick to stock vi(m) configurations as much as possible to alleviate muscle memory issues, switching seems like a step backwards to me despite the overall UI/UX language being better.