From acd5a2c3f7cab818da4c719fd98470404f7359e6 Mon Sep 17 00:00:00 2001 From: Tanaka Akira Date: Mon, 6 Sep 1999 11:36:33 +0000 Subject: zsh-development-guide and completion-style-guide is removed. --- Util/completion-style-guide | 44 -------------- Util/zsh-development-guide | 138 -------------------------------------------- 2 files changed, 182 deletions(-) delete mode 100644 Util/completion-style-guide delete mode 100644 Util/zsh-development-guide (limited to 'Util') diff --git a/Util/completion-style-guide b/Util/completion-style-guide deleted file mode 100644 index 307954760..000000000 --- a/Util/completion-style-guide +++ /dev/null @@ -1,44 +0,0 @@ -For now this is just a list of things one should or shouldn't do. - -1) Use the functions `_files' and `_path_files' instead of `compgen' - with the `-f', `-/', or `-g' options. -2) *Never* use `compgen' with the `-s' option. This can always be done - by a call to `compadd' which is faster. -3) Using `compgen' with the `-k' option should only be done if a) the - array is already existent or b) it is very large (several hundred - or thousend elements). In other cases using `compadd' is faster. -4) Supply match specifications to `compadd' and `compgen' if there are - sensible ones. -5) Use `_description' when adding matches with `compadd' or - `compgen'. Use `_message' in places where no matches can be - generated. If you want to add different types of matches, add them - with multiple calls to `compadd' or `compgen', supplying different - descriptions. -6) Use helper functions that do option completion for you (like - `_arguments' and `_long_options') -- it will make your life much - easier. -7) Use helper functions like `_users' and `_groups' instead of direct - calls to `compgen -u' or some ad hoc mechanisms to generate such - information. This ensures that user can change the way these things - will be completed everywhere by just using their own implementations - for these functions. -8) Make sure that the return value of your functions is correct: zero - if matches where added and non-zero if no matches were found. - In some cases you'll need to test the value of `$compstate[nmatches]' - for this. This should always be done by first saving the old value - (`local nm="$compstate[nmatches]"') and later comparing this with - the current value after all matches have been added (e.g. by - writing `[[ nmm -ne compstate[nmatches] ]]' at the end of your - function). This guarantees that your functions will be re-usable - because calling functions may rely on the correct return value. -9) In places where different behaviors may be useful, add a - configuration key to allow users to select the behavior they - prefer. Names for configuration keys should look like `prefix_name', - where `prefix' is the (probably abbreviated) name of your function - and `name' describes what can be configured. - When testing the values of configuration keys, the empty string - should result in the same behavior as if the key were unset. This - can be achieved by the test `[[ -n "$compconfig[prefix_name]" ]]'. -10) When writing helper functions that generate matches, the arguments - of these should be given unchanged to `compadd' or `compgen' (if - they are not used by the helper function itself). diff --git a/Util/zsh-development-guide b/Util/zsh-development-guide deleted file mode 100644 index d574d8af0..000000000 --- a/Util/zsh-development-guide +++ /dev/null @@ -1,138 +0,0 @@ ------------------------------- -GUIDELINES FOR ZSH DEVELOPMENT ------------------------------- - -Zsh is currently developed and maintained by the Zsh Development Group. -This development takes place by mailing list. Check the META-FAQ for the -various zsh mailing lists and how to subscribe to them. The development -is very open and anyone is welcomed and encouraged to join and contribute. -Because zsh is a very large package whose development can sometimes -be very rapid, I kindly ask that people observe a few guidelines when -contributing patches and feedback to the mailing list. These guidelines -are very simple and hopefully should make for a more orderly development -of zsh. - -Patches -------- - -* Send all patches to the mailing list rather than directly to me. - -* Send only context diffs "diff -c oldfile newfile". They are much - easier to read and understand while also allowing the patch program - to patch more intelligently. Please make sure the filenames in - the diff header are relative to the top-level directory of the zsh - distribution; for example, it should say "Src/init.c" rather than - "init.c" or "zsh/Src/init.c". - -* Please put only one bug fix or feature enhancement in a single patch and - only one patch per mail message. This helps me to multiplex the many - (possibly conflicting) patches that I receive for zsh. You shouldn't - needlessly split patches, but send them in the smallest LOGICAL unit. - -* If a patch depends on other patches, then please say so. Also please - mention what version of zsh this patch is for. - -* Please test your patch and make sure it applies cleanly. It takes - considerably more time to manually merge a patch into the baseline code. - -* There is now a zsh patch archive. To have your patches appear in the - archive, send them to the mailing list with a Subject: line starting - with "PATCH:". - -C coding style --------------- - -* The primary language is ANSI C as defined by the 1989 standard, but the - code should always be compatible with late K&R era compilers ("The C - Programming Language" 1st edition, plus "void" and "enum"). There are - many hacks to avoid the need to actually restrict the code to K&R C -- - check out the configure tests -- but always bear the compatibility - requirements in mind. In particular, preprocessing directives must - have the "#" unindented, and string pasting is not available. - -* Conversely, there are preprocessor macros to provide safe access to some - language features not present in pure ANSI C, such as variable-length - arrays. Always use the macros if you want to use these facilities. - -* Avoid writing code that generates warnings under gcc with the default - options set by the configure script. For example, write - "if ((foo = bar))" rather than "if (foo = bar)". - -* Please try not using lines longer than 79 characters. - -* The indent/brace style is Kernighan and Ritchie with 4 characters - indentations (with leading tab characters replacing sequences of - 8 spaces). This means that the opening brace is the last character - in the line of the if/while/for/do statement and the closing brace - has its own line: - - if (foo) { - do that - } - -* Put only one simple statement on a line. The body of an if/while/for/do - statement has its own line with 4 characters indentation even if there - are no braces. - -* Do not use space between the function name and the opening parenthesis. - Use space after if/for/while. Use space after type casts. - -* Do not use (unsigned char) casts since some compilers do not handle - them properly. Use the provided STOUC(X) macro instead. - -* If you use emacs 19.30 or newer you can put the following line to your - ~/.emacs file to make these formatting rules the default: - - (add-hook 'c-mode-common-hook (function (lambda () (c-set-style "BSD")))) - -* Function declarations must look like this: - - /**/ - int - foo(char *s, char **p) - { - function body - } - - There must be an empty line, a line with "/**/", a line with the - type of the function, and finally the name of the function with typed - arguments. These lines must not be indented. The script generating - function prototypes and the ansi2knr program depend on this format. - If the function is not used outside the file it is defined in, it - should be declared "static"; this keyword goes on the type line, - before the return type. - -* Global variable declarations must similarly be preceded by a - line containing only "/**/", for the prototype generation script. - The declaration itself should be all on one line (except for multi-line - initialisers). - -* Leave a blank line between the declarations and statements in a compound - statement, if both are present. Use blank lines elsewhere to separate - groups of statements in the interests of clarity. There should never - be two consecutive blank lines. - -Documentation -------------- - -* Edit only the .yo files. All other formats (man pages, TeXinfo, HTML, - etc.) are automatically generated from the yodl source. - -* Always use the correct markup. em() is used for emphasis, and bf() - for citations. tt() marks text that is literal input to or output - from the shell. var() marks metasyntactic variables. - -* In addition to appropriate markup, always use quotes (`') where - appropriate. Specifically, use quotes to mark text that is not a part - of the actual text of the documentation (i.e., that it is being quoted). - In principle, all combinations of quotes and markup are possible, - because the purposes of the two devices are completely orthogonal. - For example, - - Type `tt(xyzzy)' to let zsh know you have played tt(advent). - Saying `plugh' aloud doesn't have much effect, however. - - In this case, "zsh" is normal text (a name), "advent" is a command name - ocurring in the main text, "plugh" is a normal word that is being quoted - (it's the user that says `plugh', not the documentation), and "xyzzy" - is some text to be typed literally that is being quoted. -- cgit 1.4.1