-
-
Notifications
You must be signed in to change notification settings - Fork 679
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
docs: fill out the design philosophy
- Loading branch information
Showing
1 changed file
with
42 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1 +1,43 @@ | ||
## Design Philosophy | ||
|
||
First and foremost, this is a color scheme. Making colors work | ||
well takes precedence over other kinds of functionality. | ||
|
||
### UNIX Philosphy | ||
|
||
1. Write programs that do one thing and do it well. | ||
- Do colors, and do colors well. Other things like displaying the weather | ||
are not the responsibility of this plugin. | ||
1. Write programs to work together. | ||
- The full palette is exposed as user options, allowing | ||
easy integration with any other kind of tmux configuration. | ||
1. Write programs to handle text streams, because that is a universal interface. | ||
- TMUX is a text based program. Each of the palette options are strings | ||
in user options that can be piped into other programs and options. | ||
|
||
### Configurability is the root of all evil | ||
|
||
Adopted from "[Fish Shell's design philophy](https://fishshell.com/docs/current/design.html)". | ||
|
||
Every configuration option in a program is a place where the program is too | ||
stupid to figure out for itself what the user really wants, and should be | ||
considered a failure of both the program and the programmer who implemented it. | ||
|
||
Rationale: Different configuration options are a nightmare to maintain, since | ||
the number of potential bugs caused by specific configuration combinations | ||
quickly becomes an issue. Configuration options often imply assumptions about | ||
the code which change when reimplementing the code, causing issues with | ||
backwards compatibility. But mostly, configuration options should be avoided | ||
since they simply should not exist, as the program should be smart enough to do | ||
what is best, or at least a good enough approximation of it. | ||
|
||
### The law of orthogonality | ||
|
||
The set of options that do exist should have a small set of orthogonal features. | ||
Any situation where two options are related but not identical, one of them | ||
should be removed, and the other should be made powerful and general enough to | ||
handle all common use cases of either feature. | ||
|
||
Rationale: Related features make the configuration options larger, which makes | ||
it harder to use. It also increases the size of the source code, making the | ||
program harder to maintain and update. |