Gabe/techWebsite
1
0
Fork 0
Code Issues 8 Pull requests Projects 1 Releases Wiki Activity

nearing completion of cli renessance.

Browse source
This commit is contained in:
Gabe Venberg 2024-08-05 21:43:33 -05:00
parent e7d4442af6
commit 509b212c83
2 changed files with 33 additions and 13 deletions
Download patch file Download diff file Expand all files Collapse all files

46
content/posts/clirenaissance/index.md
View file

@ -80,9 +80,9 @@ ls specifically can trace its history to 1961
--> -->
Take a look at this [table](#appendix-the-tools) at the bottom of the page. Take a look at this [table](#appendix-the-tools) at the bottom of the page.
Ill wait. I'll wait.
Notice the relative scarcity between ~1995 and ~2015? Notice the relative scarcity between ~1995 and ~2015?
Id like to talk about a trend Ive seen these past few years, Id like to talk about a trend I've seen these past few years,
where people are rewriting and rethinking staples of the command line interface, where people are rewriting and rethinking staples of the command line interface,
why I think this trend might be happening, why I think this trend might be happening,
and why I think this trend is a good thing. and why I think this trend is a good thing.
@ -214,7 +214,7 @@ but its an extremely usable IDE out of the box thanks to having all of its featu
### Concise and discoverable documentation ### Concise and discoverable documentation
In my nvim config, I use [which-key](https://github.com/folke/which-key.nvim), In my Nvim config, I use [which-key](https://github.com/folke/which-key.nvim),
a plugin that displays available keybindings as you type. a plugin that displays available keybindings as you type.
I've been using vim for almost a decade, including a long time without which-key, I've been using vim for almost a decade, including a long time without which-key,
so its not like I never learned the keybindings, but I still find which-key useful. so its not like I never learned the keybindings, but I still find which-key useful.
@ -225,7 +225,7 @@ Naturally, when you go months without using certain parts of a program, you tend
Which-key solves that handily, by offering quick, non-intrusive reminders of what is available. Which-key solves that handily, by offering quick, non-intrusive reminders of what is available.
Here's what my which-key config looks like: Here's what my which-key config looks like:
![Which-key.nvim](nvim_which_key.png) ![Which-key.nvim, showing contextual key hints](nvim_which_key.png)
Now, which-key and its like have been around for a while, Now, which-key and its like have been around for a while,
but other TUI programs have integrated contextual hints without the need for a plugin. but other TUI programs have integrated contextual hints without the need for a plugin.
@ -236,15 +236,16 @@ The two that I am aware of are zellij and helix.
Helix both has autocompletion for its built in command line and a contextual hint that appears when you press the first key in a multi key combo. Helix both has autocompletion for its built in command line and a contextual hint that appears when you press the first key in a multi key combo.
This drastically helps both new and experienced users learn and remember keybinds without making the editor any less powerful. This drastically helps both new and experienced users learn and remember keybinds without making the editor any less powerful.
![Zellij's hint bar](zellij_hints.png)
Zellij has a bottom bar displaying keybindings available in the current mode. Zellij has a bottom bar displaying keybindings available in the current mode.
This has proven invaluable for me, as I don't use a terminal multiplexer much This has proven invaluable for me, as I don't use a terminal multiplexer much
(On GUI systems, I use the window manager for managing multiple terminals), and as such tend to forget the keybinds. (On GUI systems, I use the window manager for managing multiple terminals), and as such tend to forget the keybinds.
Though it does take up screen space, and a person who used Zellij every day would most likely disable it,
<!-- look at zellij and helix and their built in keymap cheatsheets--> the hints bar is more than worth it for new and occasional users.
### Common usecases should be easy ### Common usecases should be easy
<!-- look at sd, rg, and fd-->
Where possible, documentation should not even be required for the most common use cases. Where possible, documentation should not even be required for the most common use cases.
Whenever I want to use `find`, I almost always have to first look at the man page, Whenever I want to use `find`, I almost always have to first look at the man page,
as I don't use it quite often enough to memorize it. as I don't use it quite often enough to memorize it.
@ -290,15 +291,34 @@ However, Just was designed from the outset to be a command runner, and as a resu
it is much easier to pick up the just language and make a quick set of commands that can be run. it is much easier to pick up the just language and make a quick set of commands that can be run.
By leaving behind the old tool, a new tool can be made that better fits the tasks that people use the tool for. By leaving behind the old tool, a new tool can be made that better fits the tasks that people use the tool for.
## The trendsetter
<!-- did neovim kick this all off?-->
## The languages ## The languages
<!-- most of the new tools are written in rust and go.--> Now, looking back at that table, one might notice a pattern in the languages used.
While almost all tools before 2010 or so were written in C,
the language selection after that are dominated by Rust and Go.
<!-- rusts clap and gos cobra, CLI argument parsing libraries, help with this.--> Of course, there are exceptions to the pattern.
TeX was written in pascal, Neovim kept C as its primary language,
and there is the occasional new tool written in C or C++.
But there is still a clear pattern in the language choice for newly written tools.
Now, why do you think that pattern has changed?
And have these new languages led to an increase in the number of tools being written?
I think so, and I don't actually think its the languages itself, so much as the libraries surrounding them.
Both Rust and Go have healthy package ecosystems surrounding interaction with the terminal.
Rust has Clap for argument parsing, TODO for dealing with ANSI escape codes,
and Ratatui and TODO for making TUIs.
Go has a similar set of tools, with Cobra for CLI argument parsing, TODO
These libraries combined with the extra ergonomics offered by the languages themselves,
make the barrier to entry lower,
allowing for more people to experiment with the design and ergonomics of CLI tools.
## Conclusion
<!-- emphasize that the new tools are not 'better' just because they are new,
but because they take the old tools and learn what did and did not work for them. -->
## Appendix: the tools ## Appendix: the tools

BIN
content/posts/clirenaissance/zellij_hints.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 77 KiB