diff options
| -rw-r--r-- | appendices/contributing/devbook-guide/text.xml | 32 | ||||
| -rw-r--r-- | ebuild-maintenance/maintenance-tasks/text.xml | 8 | ||||
| -rw-r--r-- | ebuild-writing/common-mistakes/text.xml | 6 | ||||
| -rw-r--r-- | ebuild-writing/functions/src_install/text.xml | 4 | ||||
| -rw-r--r-- | general-concepts/use-flags/text.xml | 2 | ||||
| -rw-r--r-- | tasks-reference/completion/text.xml | 2 | ||||
| -rw-r--r-- | tools-reference/bash/text.xml | 9 |
7 files changed, 32 insertions, 31 deletions
diff --git a/appendices/contributing/devbook-guide/text.xml b/appendices/contributing/devbook-guide/text.xml index 672a083..8b8e1c0 100644 --- a/appendices/contributing/devbook-guide/text.xml +++ b/appendices/contributing/devbook-guide/text.xml @@ -13,7 +13,7 @@ <p> The guideXML syntax is lightweight yet expressive, so that it is easy to learn yet also provides all the features we need for the creation of web -documentation. The number of tags is kept to a minimum -- just those we need. +documentation. The number of tags is kept to a minimum <d/> just those we need. This makes it easy to transform guide into other formats, such as DocBook XML/SGML or web-ready HTML. </p> @@ -69,7 +69,7 @@ using GuideXML.</i> On the first lines, we see the requisite tag that identifies this as an XML document and specifies its DTD. The <c><!-- $Header$ --></c> line will be automatically modified by the CVS server and helps to track revisions. -Next, there's a <c><guide></c> tag -- the entire guide document is +Next, there's a <c><guide></c> tag <d/> the entire guide document is enclosed within a <c><guide> </guide></c> pair. </p> @@ -89,7 +89,7 @@ Then, we come to the <c><author></c> tags, which contain information about the various authors of the document. Each <c><author></c> tag allows for an optional <c>title</c> element, used to specify the author's relationship to the document (author, co-author, editor, etc.). In this -particular example, the authors' names are enclosed in another tag -- a +particular example, the authors' names are enclosed in another tag <d/> a <c><mail></c> tag, used to specify an email address for this particular person. The <c><mail></c> tag is optional and can be omitted, and at least one <c><author></c> element is required per guide document. @@ -157,9 +157,9 @@ guide document: Above, I set the chapter title by adding a child <c><title></c> element to the <c><chapter></c> element. Then, I created a section by adding a <c><section></c> element. If you look inside the -<c><section></c> element, you'll see that it has two child elements -- a +<c><section></c> element, you'll see that it has two child elements <d/> a <c><title></c> and a <c><body></c>. While the <c><title></c> -is nothing new, the <c><body></c> is -- it contains the actual text +is nothing new, the <c><body></c> is <d/> it contains the actual text content of this particular section. We'll look at the tags that are allowed inside a <c><body></c> element in a bit. </p> @@ -247,14 +247,14 @@ This is important. <body> <p> -We introduced a lot of new tags in the previous section -- here's what you need -to know. The <c><p></c> (paragraph), <c><pre></c> (code block), +We introduced a lot of new tags in the previous section <d/> here's what you +need to know. The <c><p></c> (paragraph), <c><pre></c> (code block), <c><note></c>, <c><warning></c> (warning) and <c><important></c> (important) tags all can contain one or more lines of text. Besides the <c><table></c>, <c><ul></c>, <c><ol></c> and <c><dl></c> elements (which we'll cover in just a bit), these are the only tags that should appear immediately inside a <c><body></c> element. -Another thing -- these tags <e>should not</e> be stacked -- in other words, +Another thing <d/> these tags <e>should not</e> be stacked <d/> in other words, don't put a <c><note></c> element inside a <c><p></c> element. As you might guess, the <c><pre></c> element preserves its whitespace exactly, making it well-suited for code excerpts: @@ -286,7 +286,7 @@ quickly identify commands that they need to type in. Also, because <c><c></c> elements are already offset from regular text, <e>it is rarely necessary to surround user input with double-quotes</e>. For example, don't refer to a "<c><c></c>" element like I did in this sentence. Avoiding -the use of unnecessary double-quotes makes a document more readable -- and +the use of unnecessary double-quotes makes a document more readable <d/> and adorable! </p> @@ -321,12 +321,12 @@ Fill this section with the information about the use of <p> The <c><uri></c> tag is used to point to files/locations on the Internet. -It has two forms -- the first can be used when you want to have the actual URI +It has two forms <d/> the first can be used when you want to have the actual URI displayed in the body text, such as this link to <uri>https://forums.gentoo.org/</uri>. To create this link, I typed <c><uri>https://forums.gentoo.org/</uri></c>. The alternate form is -when you want to associate a URI with some other text -- for example, <uri -link="https://forums.gentoo.org/">the Gentoo Forums</uri>. To create +when you want to associate a URI with some other text <d/> for example, +<uri link="https://forums.gentoo.org/">the Gentoo Forums</uri>. To create <e>this</e> link, I typed <c><uri link="https://forums.gentoo.org/">the Gentoo Forums</uri></c>. You don't need to write <c>https://www.gentoo.org/</c> to link to other parts of the Gentoo web site. @@ -350,7 +350,7 @@ link="https://www.w3.org/QA/Tips/noClickHere">W3C</uri>. <body> <p> -Here's how to insert a figure into a document -- <c><figure +Here's how to insert a figure into a document <d/> <c><figure link="mygfx.png" short="my picture" caption="my favorite picture of all time"/></c>. The <c>link</c> attribute points to the actual graphic image, the <c>short</c> attribute specifies a short description (currently used for @@ -372,7 +372,7 @@ tag. However, for inserting actual table data, we <e>don't</e> support the HTML <td> tag; instead, use the <c><th></c> if you are inserting a header, and <c><ti></c> if you are inserting a normal informational block. You can use a <c><th></c> anywhere you can use a <c><ti></c> --- there's no requirement that <c><th></c> elements appear only in the +<d/> there's no requirement that <c><th></c> elements appear only in the first row. </p> @@ -462,8 +462,8 @@ to <uri link="#doc_chap2_pre2">code listing 2 in chapter 2</uri>, type Since all Gentoo Documentation is a joint effort and several people will most likely change existing documentation, a coding style is needed. A coding style contains two sections. The first one is regarding -internal coding - how the XML-tags are placed. The second one is -regarding the content - how not to confuse the reader. +internal coding <d/> how the XML-tags are placed. The second one is +regarding the content <d/> how not to confuse the reader. </p> <p> diff --git a/ebuild-maintenance/maintenance-tasks/text.xml b/ebuild-maintenance/maintenance-tasks/text.xml index 50fe2f2..78abcca 100644 --- a/ebuild-maintenance/maintenance-tasks/text.xml +++ b/ebuild-maintenance/maintenance-tasks/text.xml @@ -224,14 +224,14 @@ on some architectures, then you should file a bug or ask on IRC before you upgrade the package. If you really need to get the ebuild added in a hurry, for example, for a security fix, then you should drop any <c>KEYWORDS</c> which are causing problems and CC the relevant -architectures on the bug - you should file a new bug to the +architectures on the bug <d/> you should file a new bug to the architecture in question regarding this if no bug is already available. </p> <p> If there are no new dependencies, do not remove keywords if your -commit fails with repoman - please try a full <c>git pull</c> and if +commit fails with repoman <d/> please try a full <c>git pull</c> and if you still have problems, then commit with <c>repoman -I</c> and file a bug to the broken architecture, noting it in your git commit message. </p> @@ -369,7 +369,7 @@ happens to contain an entry which may be affected by your change. <p> When removing an ebuild make sure that no dependencies in Portage are broken -due to the removal - additionally, your git commit message should explain +due to the removal <d/> additionally, your git commit message should explain clearly why the ebuild is being removed from the git repository. </p> @@ -381,7 +381,7 @@ get a newer version marked stable, then please file a bug or ask on IRC. <p> You should also not cause an unnecessary downgrade for any "<c>~arch</c>" -when removing ebuilds - instead, it is best to get the newest version +when removing ebuilds <d/> instead, it is best to get the newest version marked "<c>~arch</c>" first and then remove redundant versions of the ebuild. </p> diff --git a/ebuild-writing/common-mistakes/text.xml b/ebuild-writing/common-mistakes/text.xml index cee330d..c196e16 100644 --- a/ebuild-writing/common-mistakes/text.xml +++ b/ebuild-writing/common-mistakes/text.xml @@ -29,9 +29,9 @@ install static libraries. Instead, the <c>static-libs</c> use-flag is used for t <body> <p> The usage of <c>ROOT</c> is only designed to influence the way the package is -installed (ie. into <c>ROOT</c>) - building and compiling should not depend on -<c>ROOT</c>. As a consequence of this the usage of <c>ROOT</c> in <c>src_*</c> -functions is not allowed. +installed (ie. into <c>ROOT</c>) <d/> building and compiling should not depend +on <c>ROOT</c>. As a consequence of this the usage of <c>ROOT</c> in +<c>src_*</c> functions is not allowed. </p> <p> diff --git a/ebuild-writing/functions/src_install/text.xml b/ebuild-writing/functions/src_install/text.xml index cf453e9..19b3cee 100644 --- a/ebuild-writing/functions/src_install/text.xml +++ b/ebuild-writing/functions/src_install/text.xml @@ -152,8 +152,8 @@ compilation required) themes: <p> Or sometimes a combination of <c>insinto</c> and <c>doins</c> (plus related -functions -- see <uri link="::function-reference/install-functions"/>) <d/> the following is based -upon the <c>sys-fs/udev</c> install: +functions <d/> see <uri link="::function-reference/install-functions"/>) <d/> +the following is based upon the <c>sys-fs/udev</c> install: </p> <codesample lang="ebuild"> diff --git a/general-concepts/use-flags/text.xml b/general-concepts/use-flags/text.xml index 74cb45d..b880fa4 100644 --- a/general-concepts/use-flags/text.xml +++ b/general-concepts/use-flags/text.xml @@ -22,7 +22,7 @@ because users can set any combination of flags. <p> Packages should not configure and link based upon what is available at compile time <d/> any autodetection must be overridden. This is commonly -referred to as the dependency being "automagic" - This is bad because the +referred to as the dependency being "automagic". This is bad because the dependency is not detected by the package manager tools and can easily break, among other issues. </p> diff --git a/tasks-reference/completion/text.xml b/tasks-reference/completion/text.xml index 038bda5..bda584c 100644 --- a/tasks-reference/completion/text.xml +++ b/tasks-reference/completion/text.xml @@ -366,7 +366,7 @@ Lines 1-12 are pretty much the same as in the previous section. If <c>${prev}</c> is equal to <c>-X</c> or <c>--package-names</c>, call <c>_pkgname</c> (a function defined by <c>gentoo-bashcomp</c> that completes on package - names - it sets <c>${COMPREPLY}</c>, so we don't worry about + names <d/> it sets <c>${COMPREPLY}</c>, so we don't worry about that here). </ti> </tr> diff --git a/tools-reference/bash/text.xml b/tools-reference/bash/text.xml index 3c4f58d..98b5675 100644 --- a/tools-reference/bash/text.xml +++ b/tools-reference/bash/text.xml @@ -121,7 +121,7 @@ all new code. <p> This is because <c>[[ ]]</c> is a bash syntax construct, whereas <c>[ ]</c> is a -program which happens to be implemented as an internal -- as such, cleaner +program which happens to be implemented as an internal <d/> as such, cleaner syntax is possible with the former. For a simple illustration, consider: </p> @@ -604,9 +604,10 @@ These are used <e>outside</e> of the <c>[[ ]]</c> blocks. For operator precedenc <note> These will also sometimes work <e>inside</e> <c>[[ ]]</c> constructs, and using -<c>!</c> before a test is fairly common. <c>[[ ! -f foo ]] && bar</c> is fine. However, -there are catches -- <c>[[ -f foo && bar ]]</c> will <b>not</b> work properly, since -commands cannot be run inside <c>[[ ]]</c> blocks. +<c>!</c> before a test is fairly common. <c>[[ ! -f foo ]] && bar</c> +is fine. However, there are catches <d/> <c>[[ -f foo && bar ]]</c> +will <b>not</b> work properly, since commands cannot be run inside <c>[[ ]]</c> +blocks. </note> <p> |