Would you happen to have a script that turns a top-posted email (reply on top of the quote) into a bottom-posted one? I’ve been trying to find the time to make it myself, as I couldn’t find one already, but haven’t yet.
Ditto with a wrapper of Git to allow named staging areas.
Huh, I’m intrigued by that cupless script (as I’ve never enjoyed dealing with cups…). Seems very neat. I’d be interested to know how it is used. Is it only for network printers, or local ones too?
@lenormf could you please fix the github links in the article to make them permalinks, instead of pointing to the master branch? You can press y key on most pages on github, to make github replace master in the URL to a proper commit hash - that way you can have links that won’t bit-rot in a few weeks/months.
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.
And I will steal this paragraph, closest to my heart:
If that doesn’t sound anything special, it means that it makes sense. Unfortunately, the field of text editors on UNIX systems has over the years turned into an archipelago, in which every editor aims at being an island. Job management, shell, terminal emulation, window multiplexing… Text editors have turned into closed ecosystems (or Integrated Development Environments) that provide many (sometimes cardboard-looking) features unrelated to editing, which new comers have to buy into, or be left out in the cold.
Then why does Kakoune have a diff algorithm and a json parser among other things?
In terms of code, it also uses a few data types/algorithms that standard c++ already provides.
Then why does Kakoune have a diff algorithm and a json parser among other things? In terms of code, it also uses a few data types/algorithms that standard c++ already provides.
There’s nothing unusual about the Kakoune project having their own data structures; it’s common for C++ projects to contain functionality that’s also in the standard library.
I would say that this reflects more on the language then on the Kakoune project.
There are various places where the internal diff algorithm is used, such as in the terminal output code (on the builtin-terminal-ui branch that replaces ncurses with a custom backend), when we reload a buffer or pipe part of a buffer through an external filter, the diff algorithm allows Kakoune to know what actually changed.
Kakoune replaces some of the standard library utilities with its own for various reasons, HashMap is used instead of std::unordered_map to provide slightly different semantics (iteration order matches insertion order for example) and better performance (HashMap uses open addressing), RefPtr is used instead of shared_ptr because we use an intrusive ref count and we share the implementation with SafePtr (a pointer type that makes an object assert at destruction if any pointers to it remain alive).
Are you aware of the article (written by the creator of the project himself) titled “Why Kakoune?”, though? I didn’t expect that my article could be seen as an argument for the editor, it’s an interesting angle.
I was not aware of it, thanks for sharing. Even if it is much more “why”, it is also much longer :-). And programmers love to steal in my experience :-).
I use Newsboat as a backend for fetching RSS items.
I wrote Newsboat-Sendmail which taps into the Newsboat cache to send emails to a dedicated email address.
To make sure the IDs of the emails’ subjects are kept whenever the server asks me to wait before sending more emails, I wrote Sendmail-TryQueue. It saves emails that could not be sent on disk (readable EML format, plus shell script for the exact sendmail command that was used).
Finally I use Alot to manage the notifications/items.
Ah, I think I misunderstood its features and your workflow. And now I’m curious. How does the non-RSS bit work? Do you customize & redeploy when adding new sources? In other words, how easy or hard is it to generalize extracting the useful bits, especially in today’s world of “CSS-in-JS” where sane as in human-friendly class names go away?
So, the current incarnation has several builtins, each wrapping a simpler primitive:
The simplest is just ‘specify a feed url and it’ll grab the content from the feed and mail it to you’.
The next simplest-but-useful is ‘specify a feed url and it’ll grab the link from the feed, fetch the link, parse it as html, extract all content matching a css selector, inline any images, and mail it to you’. This works well for eg webcomics.
The third level replaces ‘fetch the link’ with ‘fire up chrome to fetch the link’ but is otherwise similar.
My planned-future changes:
Use chromedriver but specify the window size and content coordinates; this should work around css-in-js issues by looking for boxes of approximately the right size / position in the document. I’m not currently following any feeds that need this, though.
Store values and look for changes. I plan to use this to (eg) monitor price changes on shopping sites.
Yeah, it’s pretty frustrating that software has seemingly gotten as wasteful as it has. I think this is a consequence of the power of abstraction – we’re building on the shoulders of giants on the shoulders of giants. That silky smooth text editor on a 286 was essentially 100% bespoke, with every line of code contributing. Now our text editors are built with GUI toolkits and powerful, yet general purpose edit controls…so we drag in all sorts of stuff that we don’t need. This is the sacrifice we make at the altar of code reuse.
Whether or not this is a good thing is up for debate. But I think it’s unavoidable with the particular combination of software demand, economies of scale in hardware, and labor pool that we have in this world we’re stuck with.
There are different scales of tradeoff in code reuse, though. Very often, using some third-party library takes more effort than implementing the facilities you were going to use with builtin facilities (particularly if you’re working in a language with a feature-rich standard library, like python) – and this problem gets worse the more bloated the library is. We buy into some framework because of flashy features we will never use, then waste a lot of time learning the framework’s special ways of doing things, and in the end the code we wrote is unportable and the sunk cost fallacy keeps us from doing the sensible thing & throwing it out.
The most irritating thing, for me, is that good-enough performance isn’t very hard for most common tasks & doesn’t require any special knowledge. If you write something in python and you do it in the most straightforward way possible, with no particular emphasis on optimization, it’s still going to be hard to make it too slow (the example in the post about a python command line script running for 1.5 seconds is sort of absurd, unless it’s doing a bunch of complex math without the help of numpy). Even so, basically everything we use – including most common open source applications – are substantially slower than the minimum acceptable performance, for no clear & defensible reason.
You can make a milky-smooth text editor in about three lines of python – Tk ships with a fast & powerful text widget that does about 90% of what you want from a rich text editor. In other words, it’s literally easier to make it fast than to make it slow, so long as you are willing to avoid being sucked into dumping cycles into unnecessary facilities.
Thanks, I actually gave it a try recently. I’m a recent convert from emacs to sublime and miss the ability to use my editor over an ssh session. I like everything about kakoune but the modal editing is a tough change for me. If kakoune was made as a modern emacs rather than vim it would have been an instant win for me!
Find lots of tools I have in my
~/binhere: https://leahneukirchen.org/dotfiles/tools.htmlInteresting is, maybe:
And lots of more goodies in my .zshrc.
Thanks, these are helpful.
Would you happen to have a script that turns a top-posted email (reply on top of the quote) into a bottom-posted one? I’ve been trying to find the time to make it myself, as I couldn’t find one already, but haven’t yet.
Ditto with a wrapper of Git to allow named staging areas.
Conversion, no, there is t-prot which strips the bottom full quote.
You can do the latter with multiple GIT_INDEX_FILE but it gets messy. I don’t know better tooling on top.
(Personally, I use git-revise to amend to older patches.)
These date tools are hilarious. Do you actually have use for the days since the french revolution? Is that what it does?
my favorite date tool: https://linux.die.net/man/1/ddate. It’s a shame it was removed from coreutils.
It’s the French “metric” calendar they used for a few years after the revolution. It’s one part that didn’t really stick.
At any rate, this is a nice date-related script I often use (
tz):Just
tzwill print the times in all the timezones, andtz 1900(ortz 19:00,tz 7pm) will print the times corresponding to 19:00 in all the timezones.I was mostly interested in the decimal time, but then I went with it and implemented the calendar too.
Huh, I’m intrigued by that cupless script (as I’ve never enjoyed dealing with cups…). Seems very neat. I’d be interested to know how it is used. Is it only for network printers, or local ones too?
Network printers that speak JetDirect.
@lenormf could you please fix the github links in the article to make them permalinks, instead of pointing to the
masterbranch? You can pressykey on most pages on github, to make github replacemasterin the URL to a proper commit hash - that way you can have links that won’t bit-rot in a few weeks/months.Thanks for the feedback, that’s helpful. I’ve updated the links to have them point to code from the latest release (
v2020.09.01).The ASCII Clippy.
And Dilbert!
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.
This article is a very nice read. I will be using it as an answer to the many people asking me why kak?
I have switched almost a year ago and I cannot imagine myself going back to any other editors I have used before.
And I will steal this paragraph, closest to my heart:
Then why does Kakoune have a diff algorithm and a json parser among other things? In terms of code, it also uses a few data types/algorithms that standard c++ already provides.
There’s nothing unusual about the Kakoune project having their own data structures; it’s common for C++ projects to contain functionality that’s also in the standard library.
I would say that this reflects more on the language then on the Kakoune project.
There are various places where the internal diff algorithm is used, such as in the terminal output code (on the builtin-terminal-ui branch that replaces ncurses with a custom backend), when we reload a buffer or pipe part of a buffer through an external filter, the diff algorithm allows Kakoune to know what actually changed.
Kakoune replaces some of the standard library utilities with its own for various reasons, HashMap is used instead of std::unordered_map to provide slightly different semantics (iteration order matches insertion order for example) and better performance (HashMap uses open addressing), RefPtr is used instead of shared_ptr because we use an intrusive ref count and we share the implementation with SafePtr (a pointer type that makes an object assert at destruction if any pointers to it remain alive).
I think you are mixing two concepts, but I can understand you wrong.
In Dutch, kak is slang for poop / shit. So I find your statement funny, why kak.
Well, it is usual abbreviation of the program. My bad, as it is very similar in Czech (and some other Slavic langs). So better, Why Kakoune?
Thanks!
Are you aware of the article (written by the creator of the project himself) titled “Why Kakoune?”, though? I didn’t expect that my article could be seen as an argument for the editor, it’s an interesting angle.
I was not aware of it, thanks for sharing. Even if it is much more “why”, it is also much longer :-). And programmers love to steal in my experience :-).
I wrote a cron job that fetches RSS feeds and pipes new items into a folder in my emails.
Advantages:
Disadvantages:
I use Newsboat as a backend for fetching RSS items.
I wrote Newsboat-Sendmail which taps into the Newsboat cache to send emails to a dedicated email address.
To make sure the IDs of the emails’ subjects are kept whenever the server asks me to wait before sending more emails, I wrote Sendmail-TryQueue. It saves emails that could not be sent on disk (readable EML format, plus shell script for the exact sendmail command that was used).
Finally I use Alot to manage the notifications/items.
…so basically Thunderbird.
Thunderbird is one client.
I can also use it via the fastmail web ui, or my phone.
Lastly, the chromedriver integration means I get full articles with images, instead of snippets.
Ah, I think I misunderstood its features and your workflow. And now I’m curious. How does the non-RSS bit work? Do you customize & redeploy when adding new sources? In other words, how easy or hard is it to generalize extracting the useful bits, especially in today’s world of “CSS-in-JS” where sane as in human-friendly class names go away?
So, the current incarnation has several builtins, each wrapping a simpler primitive:
My planned-future changes:
haha, I like this one. You’ve turned RSS into newsletters!
mailchimp sells this as a feature.
I use rss2email which basically does the same thing.
I wrote a rss reader which is meant for cronjobs, which is btw the reader I use.
https://gitlab.com/dacav/crossbow
The version 0.9.0 is usable. Soon I plan to release version 1.0.0
Yeah, it’s pretty frustrating that software has seemingly gotten as wasteful as it has. I think this is a consequence of the power of abstraction – we’re building on the shoulders of giants on the shoulders of giants. That silky smooth text editor on a 286 was essentially 100% bespoke, with every line of code contributing. Now our text editors are built with GUI toolkits and powerful, yet general purpose edit controls…so we drag in all sorts of stuff that we don’t need. This is the sacrifice we make at the altar of code reuse.
Whether or not this is a good thing is up for debate. But I think it’s unavoidable with the particular combination of software demand, economies of scale in hardware, and labor pool that we have in this world we’re stuck with.
It sounds like the challenge going forward is collapsing these towers of dependencies. Like the Zen of Python says:
There are different scales of tradeoff in code reuse, though. Very often, using some third-party library takes more effort than implementing the facilities you were going to use with builtin facilities (particularly if you’re working in a language with a feature-rich standard library, like python) – and this problem gets worse the more bloated the library is. We buy into some framework because of flashy features we will never use, then waste a lot of time learning the framework’s special ways of doing things, and in the end the code we wrote is unportable and the sunk cost fallacy keeps us from doing the sensible thing & throwing it out.
The most irritating thing, for me, is that good-enough performance isn’t very hard for most common tasks & doesn’t require any special knowledge. If you write something in python and you do it in the most straightforward way possible, with no particular emphasis on optimization, it’s still going to be hard to make it too slow (the example in the post about a python command line script running for 1.5 seconds is sort of absurd, unless it’s doing a bunch of complex math without the help of numpy). Even so, basically everything we use – including most common open source applications – are substantially slower than the minimum acceptable performance, for no clear & defensible reason.
You can make a milky-smooth text editor in about three lines of python – Tk ships with a fast & powerful text widget that does about 90% of what you want from a rich text editor. In other words, it’s literally easier to make it fast than to make it slow, so long as you are willing to avoid being sucked into dumping cycles into unnecessary facilities.
Bouncing off of your statement about text editors, I suggest you check out Kakoune, it’s a modal code editor that packs a punch.
Thanks, I actually gave it a try recently. I’m a recent convert from emacs to sublime and miss the ability to use my editor over an ssh session. I like everything about kakoune but the modal editing is a tough change for me. If kakoune was made as a modern emacs rather than vim it would have been an instant win for me!