FWIW, zsh has a commands hash to make stuff like this potentially easier and cleaner. The following isn't quite how I'd do it, but is functionally equivalent.
(( $+commands[vim] )) && alias vi=vim
(( $+commands[nvim] )) && alias vi{,m}=nvim
I wasn't aware of +commands, thanks. Though I'm not sure this is easier and you can translate mine to bash trivially
Yours isn't technically equivalent though it is functionally. If we have both vim and nvim then we'll alias vi twice.
Also, your program provides less clarity. It saves lines but at a large cost to readability. I tend to share my dotfiles with newbies a lot so readability is very meaningful.
I wrap mine up in functions too because at the end of my alias file I can add something like this
It's a bit overkill and I never expect a simple alias like that to fail but there are three distinct advantages I get for being just a tad more verbose:
1) I have more complicated versions to deal with things like fd and batcat which have different names different operating systems (`fd` vs `fd-find` / `bat` vs `batcat`) and some additional configurations.
2) I can disable the alias by commenting out one line
3) knowing exactly where the alias is being loaded and thus what aliases are loaded.
Bonus) fails loudly but continues (it's an alias, I don't want you fail fail)
A few extra keystrokes are worth this advantage imo. Especially since I'm using vim so it's actually not any additional typing lol
It's style, so the choice is up to you and they'll accomplish the same things, but I'm just explaining why I use this design pattern. I've only given a stripped down snippet of code so I hope this context helps explain the larger pictures and how it can be used for larger needs.
You can, it even ships with two files you can use as examples in mc.{emacs,vim}.keymap. The vim one has my favorite comment in a config file:
[editor]
# No remapping, just use vim instead of mcedit
Given that you can specify the bindings config to use at startup with --keymap you can even configure task specific sets of bindings. This combined with extfs and custom menus makes it a great way to make a personal interface to non-file data sources too.
There is also a `-b` flag to get it back in to the shape you'd expect from cal. I find the week column easier to read in that form:
w| Mo Tu We Th Fr Sa Su
31| 1 2 3
32| 4 5 6 7 8 9 10
Perhaps worth noting that ncal's -w is ISO-8601 compliant¹, which may surprise some people around new year as week numbers can reset in December or January.
[Said as someone who aliases cal to "ncal -wb" mostly just to get the correct first day of the week for their locale.]
There is the complete-filename function that only completes filenames in bash, bound to M-/ by default. You can use that in any place you want a filename where "complete"(the function normally bound to tab) would do something you don't desire.
There are a collection of other non-context aware completion functions that are bound by default too, useful for example when you when you wish to complete hostnames in a for-loop.
zle has what is largely a significant superset of this, the documentation is spread about between the zshzle and zshcomp* manpages.
Somewhat predictably zsh also has a digraphs¹ feature, via the insert-composed-char function². Supported characters can be seen in source³, and beyond that there is the insert-unicode-char² function for when you need it.
I flit between regular compose key input and zsh/vim digraphs in a way that makes no sense to me whatsoever. Compose ^1, AltGr+1 or C-k 1S all kind of feel natural to me, but the advantage of the ZLE method is that you can also use it to preview characters which can be useful if you want to test something out while in another widget or find the hex value to insert using some other tool.
To be fair, if all you want is a package with Debian you can do that too. Just copy files in to a dir(like package() in your Arch example), write a 10 line DEBIAN/control in there(like the preamble in your Arch example), and call "dpkg-deb --build". The linked document is describing something different, joeyh has a short "why?"¹ from years ago that may be helpful.
What is different in OP that makes that approach not suitable? The git upstream? In the AUR example I gave, pkgver() auto-updates $pkgver, which will show up in version control. You can run `makepkg -defo` (or -dfo I forget which rn) to just run pkgver().
At least once a year for the past couple of decades I'll receive an email from a user that makes me want to modernize bfm¹. However, I've never managed to get an auto-scaling version to work with reasonable performance, which is unbelievably annoying for such a simple tool. You can sort of hit the target for gkrellm-bfm while still depending on GTK2, or for the standalone bubblefishymon wmapplet where you can use a modern GTK² or jump straight to SDL.
Never in a way that doesn't noticeably chew additional CPU though, and definitely not for both use cases. It upsets me each time I reply "no, not happening without patches". Perhaps it is time to release an Electron version or one that just burns a whole CPU core so it isn't lost forever ;)
¹ It used to just be people with crazy setups, now it is basically any screen given their higher DPI.
² As it is right now I don't even have a system that I can use last release on.
Some of the background was explained before¹, along with a heap of comments when it was posted here².
Probably still not enough information for an outside observer(like me), but they probably assume more familiarity with the project for posts on their discourse.
