aboutsummaryrefslogtreecommitdiffhomepage
path: root/doc_src/design.hdr
diff options
context:
space:
mode:
authorGravatar Mark Griffiths <mark@thebespokepixel.com>2014-09-08 07:05:53 +0100
committerGravatar Mark Griffiths <mark@thebespokepixel.com>2014-09-08 07:05:53 +0100
commit6b75a4593bb2f5a4b3b1bdf3333f50ef94c20da5 (patch)
treec53f05f35388f335dc9b54831a486fd20fae66f7 /doc_src/design.hdr
parenta04d5fd065a8839767bcbe4adafbbdf0889d5c10 (diff)
parent8643a5e2666bf043dcc53a9a3694e98f7475aa08 (diff)
Merge remote-tracking branch 'upstream/master' into documentation-update
Conflicts (resolved): doc_src/design.hdr - \c changed to backticks
Diffstat (limited to 'doc_src/design.hdr')
-rw-r--r--doc_src/design.hdr21
1 files changed, 10 insertions, 11 deletions
diff --git a/doc_src/design.hdr b/doc_src/design.hdr
index 0ba578e4..c57943c5 100644
--- a/doc_src/design.hdr
+++ b/doc_src/design.hdr
@@ -24,7 +24,8 @@ To achieve these high-level goals, the fish design relies on a number of more sp
The shell language should have a small set of orthogonal features. Any situation where two features 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 language larger, which makes it harder to learn. It also increases the size of the sourcecode, making the program harder to maintain and update.
+
+Related features make the language larger, which makes it harder to learn. It also increases the size of the source code, making the program harder to maintain and update.
Examples:
@@ -63,25 +64,24 @@ Examples:
- Fish does not allow you to set the history filename, the number of history entries, different language substyles or any number of other common shell configuration options.
-A special note on the evils of configurability is the long list of very useful features found in some shells, that are not turned on by default. Both zsh and bash support command specific completions, but no such completions are shipped with bash by default, and they are turned off by default in zsh. Other features that zsh support that are disabled by default include tab-completion of strings containing wildcards, a sane completion pager and a history file.
-
+A special note on the evils of configurability is the long list of very useful features found in some shells, that are not turned on by default. Both zsh and bash support command-specific completions, but no such completions are shipped with bash by default, and they are turned off by default in zsh. Other features that zsh supports that are disabled by default include tab-completion of strings containing wildcards, a sane completion pager and a history file.
\section user The law of user focus
When designing a program, one should first think about how to make a intuitive and powerful program. Implementation issues should only be considered once a user interface has been designed.
Rationale:
-This design rule is different than the others, since it describes how one should go about designing new features, not what the features should be. The problem with focusing on what can be done, and what is easy to do, is that to much of the implementation is exposed. This means that the user must know a great deal about the underlying system to be able to guess how the shell works, it also means that the language will often be rather low-level.
+
+This design rule is different than the others, since it describes how one should go about designing new features, not what the features should be. The problem with focusing on what can be done, and what is easy to do, is that too much of the implementation is exposed. This means that the user must know a great deal about the underlying system to be able to guess how the shell works, it also means that the language will often be rather low-level.
Examples:
- There should only be one type of input to the shell, lists of commands. Loops, conditionals and variable assignments are all performed through regular commands.
-- The differences between builtin commands and shellscript functions should be made as small as possible. Builtins and shellscript functions should have exactly the same types of argument expansion as other commands, should be possible to use in any position in a pipeline, and should support any io redirection.
+- The differences between built-in commands and shellscript functions should be made as small as possible. Built-ins and shellscript functions should have exactly the same types of argument expansion as other commands, should be possible to use in any position in a pipeline, and should support any I/O redirection.
- Instead of forking when performing command substitution to provide a fake variable scope, all fish commands are performed from the same process, and fish instead supports true scoping.
-- All blocks end with the `end` builtin.
-
+- All blocks end with the `end` built-in.
\section disc The law of discoverability
@@ -90,17 +90,16 @@ A program should be designed to make its features as easy as possible to discove
Rationale:
A program whose features are discoverable turns a new user into an expert in a shorter span of time, since the user will become an expert on the program simply by using it.
-The main benefit of a graphical program over a command line-based program is discoverability. In a graphical program, one can discover all the common features by simply looking at the user interface and guessing what the different buttons, menus and other widgets do. The traditional way to discover features in commandline programs is through manual pages. This requires both that the user starts to use a different program, and then she/he remembers the new information until the next time she/he uses the same program.
+The main benefit of a graphical program over a command-line-based program is discoverability. In a graphical program, one can discover all the common features by simply looking at the user interface and guessing what the different buttons, menus and other widgets do. The traditional way to discover features in command-line programs is through manual pages. This requires both that the user starts to use a different program, and then she/he remembers the new information until the next time she/he uses the same program.
Examples:
- Everything should be tab-completable, and every tab completion should have a description.
-- Every syntax error and error in a builtin command should contain an error message describing what went wrong and a relevant help page. Whenever possible, errors should be flagged red by the syntax highlighter.
+- Every syntax error and error in a built-in command should contain an error message describing what went wrong and a relevant help page. Whenever possible, errors should be flagged red by the syntax highlighter.
- The help manual should be easy to read, easily available from the shell, complete and contain many examples
-- The language should be uniform, so that once the user understands the command/argument syntax, he will know the whole language, and be able to use tab-completion to discover new featues.
-
+- The language should be uniform, so that once the user understands the command/argument syntax, she/he will know the whole language, and be able to use tab-completion to discover new features.
\htmlonly[block]