diff --git a/en_US.ISO8859-1/books/fdp-primer/psgml-mode/chapter.sgml b/en_US.ISO8859-1/books/fdp-primer/psgml-mode/chapter.sgml index d912db05c2..8324cb979f 100644 --- a/en_US.ISO8859-1/books/fdp-primer/psgml-mode/chapter.sgml +++ b/en_US.ISO8859-1/books/fdp-primer/psgml-mode/chapter.sgml @@ -1,165 +1,165 @@ Using <literal>sgml-mode</literal> with <application>Emacs</application> Recent versions of Emacs or XEmacs (available from the ports collection) contain a very useful package called PSGML. Automatically invoked when a file with the .sgml extension is loaded, or by typing M-x sgml-mode, it is a major mode for dealing with SGML files, elements and attributes. An understanding of some of the commands provided by this mode can make working with SGML documents such as the Handbook much easier. C-c C-e Runs sgml-insert-element. You will be prompted for the name of the element to insert at the current point. You can use the TAB key to complete the element. Elements that are not valid at the current point will be disallowed. The start and end tags for the element will be inserted. If the element contains other, mandatory, elements then these will be inserted as well. C-c = Runs sgml-change-element-name. Place the point within an element and run this command. You will be prompted for the name of the element to change to. Both the start and end tags of the current element will be changed to the new element. C-c C-r Runs sgml-tag-region. Select some text (move to start of text, C-space, move to end of text, C-space) and then run this command. You will be prompted for the element to use. This element will then be inserted immediately before and after your marked region. C-c - Runs sgml-untag-element. Place the point within the start or end tag of an element you want to remove, and run this command. The element's start and end tags will be removed. C-c C-q Runs sgml-fill-element. Will recursively fill (i.e., reformat) content from the current element in. The filling will affect content in which whitespace is significant, such as within programlisting elements, so run this command with care. C-c C-a Runs sgml-edit-attributes. Opens a second buffer containing a list of all the attributes for the closest enclosing element, and their current values. Use TAB to navigate between attributes, C-k to remove an existing value and replace it with a new one, C-c C-c to close this buffer and return to the main document. C-c C-v Runs sgml-validate. Prompts you to save the current document (if necessary) and then runs an SGML validator. The output from the validator is captured into a new buffer, and you can then navigate from one troublespot to the next, fixing markup errors as you go. Doubtless there are other useful functions of this mode, but those are the ones I use most often. You can also use the following entries in .emacs to set proper spacing, indentation, and column width for working with the Documentation Project. (setq sgml-mode-hook '(lambda () - (setq fill-column 70 + (setq fill-column 78 indent-tabs-mode nil next-line-add-newlines nil standard-indent 2) (auto-fill-mode t))) diff --git a/en_US.ISO8859-1/books/fdp-primer/writing-style/chapter.sgml b/en_US.ISO8859-1/books/fdp-primer/writing-style/chapter.sgml index 79d9ff17af..049007aada 100644 --- a/en_US.ISO8859-1/books/fdp-primer/writing-style/chapter.sgml +++ b/en_US.ISO8859-1/books/fdp-primer/writing-style/chapter.sgml @@ -1,480 +1,480 @@ Writing style In order to promote consistency between the myriad authors of the FreeBSD documentation, some guidelines have been drawn up for authors to follow. Use American English spelling There are several variants of English, with different spellings for the same word. Where spellings differ, use the American English variant. color, not colour, rationalize, not rationalise, and so on. Do not use contractions Do not use contractions. Always spell the phrase out in full. Don't use contractions would be wrong. Avoiding contractions makes for a more formal tone, is more precise, and is slightly easier for translators. Use the serial comma In a list of items within a paragraph, separate each item from the others with a comma. Separate the last item from the others with a comma and the word and. For example, look at the following:
This is a list of one, two and three items.
Is this a list of three items, one, two, and three, or a list of two items, one and two and three? It is better to be explicit and include a serial comma:
This is a list of one, two, and three items.
Avoid redundant phrases Try not to use redundant phrases. In particular, the command, the file, and man command are probably redundant. These two examples show this for commands. The second example is preferred. Use the command cvsup to update your sources Use cvsup to update your sources These two examples show this for filenames. The second example is preferred. … in the filename /etc/rc.local… … in /etc/rc.local… These two examples show this for manual references. The second example is preferred (the second example uses citerefentry). See man csh for more information. See &man.csh.1; Two spaces at the end of sentences Always use two spaces at the end of sentences, as this improves readability, and eases use of tools such as Emacs. While it may be argued that a capital letter following a period denotes a new sentence, this is not the case, especially in name usage. Jordan K. Hubbard is a good example; it has a capital H following a period and a space, and there certainly is not a new sentence there. For more information about writing style, see Elements of Style, by William Strunk. Style guide To keep the source for the Handbook consistent when many different people are editing it, please follow these style conventions. Letter case Tags are entered in lower case, <para>, not <PARA>. Text that appears in SGML contexts is generally written in upper case, <!ENTITY…>, and <!DOCTYPE…>, not <!entity…> and <!doctype…>. Acronyms Acronyms should generally be spelled out the first time they appear in a book, as in: "Network Time Protocol (NTP)." After the acronym has been defined, you should generally use the acronym only (not the whole term, unless it makes more sense contextually to use the whole term). Usually, acronyms are defined only one per book. But if you prefer, you can also define them the first time they appear in each chapter. The first three uses of an acronym should be enclosed in <acronym> tags, with a role attribute with the full term defined. This allows a link to the glossary to be created, and for mouseovers to be rendered with the fully expanded term. Indentation Each file starts with indentation set at column 0, regardless of the indentation level of the file which might contain this one. Opening tags increase the indentation level by 2 spaces. Closing tags decrease the indentation level by 2 spaces. Blocks of 8 spaces at the start of a line should be replaced with a tab. Do not use spaces in front of tabs, and do not add extraneous whitespace at the end of a line. Content within elements should be indented by two spaces if the content runs over more than one line. For example, the source for this section looks something like: ... ... Indentation Each file starts with indentation set at column 0, regardless of the indentation level of the file which might contain this one. ... ]]> If you use Emacs or XEmacs to edit the files then sgml-mode should be loaded automatically, and the Emacs local variables at the bottom of each file should enforce these styles. Vim users might want to configure their editor with: augroup sgmledit autocmd FileType sgml set formatoptions=cq2l " Special formatting options - autocmd FileType sgml set textwidth=70 " Wrap lines at 70 spaces + autocmd FileType sgml set textwidth=78 " Wrap lines at 78 columns autocmd FileType sgml set shiftwidth=2 " Automatically indent autocmd FileType sgml set softtabstop=2 " Tab key indents 2 spaces autocmd FileType sgml set tabstop=8 " Replace 8 spaces with a tab autocmd FileType sgml set autoindent " Automatic indentation augroup END Tag style Tag spacing Tags that start at the same indent as a previous tag should be separated by a blank line, and those that are not at the same indent as a previous tag should not: NIS October 1999 ... ... ... ... ... ... ... ]]> Separating tags Tags like itemizedlist which will always have further tags inside them, and in fact do not take character data themselves, are always on a line by themselves. Tags like para and term do not need other tags to contain normal character data, and their contents begin immediately after the tag, on the same line. The same applies to when these two types of tags close. This leads to an obvious problem when mixing these tags. When a starting tag which cannot contain character data directly follows a tag of the type that requires other tags within it to use character data, they are on separate lines. The second tag should be properly indented. When a tag which can contain character data closes directly after a tag which cannot contain character data closes, they co-exist on the same line. White space changes When committing changes, do not commit changes to the content at the same time as changes to the formatting. This is so that the teams that convert the Handbook to other languages can quickly see what content has actually changed in your commit, without having to decide whether a line has changed because of the content, or just because it has been refilled. For example, if you have added two sentences to a paragraph, such that the line lengths on the paragraph now go over 80 columns, first commit your change with the too-long line lengths. Then fix the line wrapping, and commit this second change. In the commit message for the second change, be sure to indicate that this is a whitespace-only change, and that the translation team can ignore it. Nonbreaking space Avoid line breaks in places where they look ugly or make it difficult to follow a sentence. Line breaks depend on the width of the chosen output medium. In particular, viewing the HTML documentation with a text browser can lead to badly formatted paragraphs like the next one: Data capacity ranges from 40 MB to 15 GB. Hardware compression … The general entity &nbsp; prohibits line breaks between parts belonging together. Use nonbreaking spaces in the following places: between numbers and units: between program names and version numbers: between multiword names (use with caution when applying this to more than 3-4 word names like The FreeBSD Brazilian Portuguese Documentation Project): Word list The following is a small list of words spelled the way they should be used in the FreeBSD Documentation Project. If the word you are looking for is not in this list, then please consult the O'Reilly word list. 2.2.X 4.X-STABLE CDROM DoS (Denial of Service) FreeBSD Ports Collection IPsec Internet MHz Soft Updates Unix disk label email file system manual page mail server name server ports collection web server