nearing completion of cli renessance.
This commit is contained in:
parent
e7d4442af6
commit
509b212c83
|
@ -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.
|
||||
Ill wait.
|
||||
I'll wait.
|
||||
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,
|
||||
why I think this trend might be happening,
|
||||
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
|
||||
|
||||
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.
|
||||
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.
|
||||
|
@ -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.
|
||||
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,
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
|
||||
<!-- look at zellij and helix and their built in keymap cheatsheets-->
|
||||
Though it does take up screen space, and a person who used Zellij every day would most likely disable it,
|
||||
the hints bar is more than worth it for new and occasional users.
|
||||
|
||||
### 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.
|
||||
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.
|
||||
|
@ -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.
|
||||
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
|
||||
|
||||
<!-- 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
|
||||
|
||||
|
|
BIN
content/posts/clirenaissance/zellij_hints.png
Normal file
BIN
content/posts/clirenaissance/zellij_hints.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 77 KiB |
Loading…
Reference in a new issue