aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorUlrich Müller <ulm@gentoo.org>2019-12-04 19:05:40 +0100
committerUlrich Müller <ulm@gentoo.org>2019-12-08 12:32:06 +0100
commitb4d66635da300177037ebd65b3f33e2180007f98 (patch)
tree0dfc113adfeb004c7c9c7a463f1d87d2d687bd57
parentbin/gen-eclass-html.sh: Fix text.xml output. (diff)
downloaddevmanual-b4d66635da300177037ebd65b3f33e2180007f98.tar.gz
devmanual-b4d66635da300177037ebd65b3f33e2180007f98.tar.bz2
devmanual-b4d66635da300177037ebd65b3f33e2180007f98.zip
Use <d/> for dashes throughout.
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
-rw-r--r--appendices/contributing/devbook-guide/text.xml32
-rw-r--r--ebuild-maintenance/maintenance-tasks/text.xml8
-rw-r--r--ebuild-writing/common-mistakes/text.xml6
-rw-r--r--ebuild-writing/functions/src_install/text.xml4
-rw-r--r--general-concepts/use-flags/text.xml2
-rw-r--r--tasks-reference/completion/text.xml2
-rw-r--r--tools-reference/bash/text.xml9
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>&lt;!-- &#36;Header&#36; --&gt;</c> line
will be automatically modified by the CVS server and helps to track revisions.
-Next, there's a <c>&lt;guide&gt;</c> tag -- the entire guide document is
+Next, there's a <c>&lt;guide&gt;</c> tag <d/> the entire guide document is
enclosed within a <c>&lt;guide&gt; &lt;/guide&gt;</c> pair.
</p>
@@ -89,7 +89,7 @@ Then, we come to the <c>&lt;author&gt;</c> tags, which contain information
about the various authors of the document. Each <c>&lt;author&gt;</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>&lt;mail&gt;</c> tag, used to specify an email address for this particular
person. The <c>&lt;mail&gt;</c> tag is optional and can be omitted, and at
least one <c>&lt;author&gt;</c> element is required per guide document.
@@ -157,9 +157,9 @@ guide document:
Above, I set the chapter title by adding a child <c>&lt;title&gt;</c>
element to the <c>&lt;chapter&gt;</c> element. Then, I created a section by
adding a <c>&lt;section&gt;</c> element. If you look inside the
-<c>&lt;section&gt;</c> element, you'll see that it has two child elements -- a
+<c>&lt;section&gt;</c> element, you'll see that it has two child elements <d/> a
<c>&lt;title&gt;</c> and a <c>&lt;body&gt;</c>. While the <c>&lt;title&gt;</c>
-is nothing new, the <c>&lt;body&gt;</c> is -- it contains the actual text
+is nothing new, the <c>&lt;body&gt;</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>&lt;body&gt;</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>&lt;p&gt;</c> (paragraph), <c>&lt;pre&gt;</c> (code block),
+We introduced a lot of new tags in the previous section <d/> here's what you
+need to know. The <c>&lt;p&gt;</c> (paragraph), <c>&lt;pre&gt;</c> (code block),
<c>&lt;note&gt;</c>, <c>&lt;warning&gt;</c> (warning) and
<c>&lt;important&gt;</c> (important) tags all can contain one or more lines of
text. Besides the <c>&lt;table&gt;</c>, <c>&lt;ul&gt;</c>, <c>&lt;ol&gt;</c>
and <c>&lt;dl&gt;</c> elements (which we'll cover in just a bit), these are the
only tags that should appear immediately inside a <c>&lt;body&gt;</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>&lt;note&gt;</c> element inside a <c>&lt;p&gt;</c> element. As
you might guess, the <c>&lt;pre&gt;</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>&lt;c&gt;</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>&lt;c&gt;</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>&lt;uri&gt;</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>&lt;uri&gt;https://forums.gentoo.org/&lt;/uri&gt;</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>&lt;uri link="https://forums.gentoo.org/"&gt;the
Gentoo Forums&lt;/uri&gt;</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>&lt;figure
+Here's how to insert a figure into a document <d/> <c>&lt;figure
link="mygfx.png" short="my picture" caption="my favorite picture of all
time"/&gt;</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
&lt;td&gt; tag; instead, use the <c>&lt;th&gt;</c> if you are inserting a
header, and <c>&lt;ti&gt;</c> if you are inserting a normal informational
block. You can use a <c>&lt;th&gt;</c> anywhere you can use a <c>&lt;ti&gt;</c>
--- there's no requirement that <c>&lt;th&gt;</c> elements appear only in the
+<d/> there's no requirement that <c>&lt;th&gt;</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 ]] &amp;&amp; bar</c> is fine. However,
-there are catches -- <c>[[ -f foo &amp;&amp; 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 ]] &amp;&amp; bar</c>
+is fine. However, there are catches <d/> <c>[[ -f foo &amp;&amp; bar ]]</c>
+will <b>not</b> work properly, since commands cannot be run inside <c>[[ ]]</c>
+blocks.
</note>
<p>