fix problematic HTML caused by certain trailing backslashes

In cases that are **outside of a markdown code block**,
a markdown line with ending in a tailing "\" can generate
problematic HTML.

We certain trailing backslashes outside of a markdown code block
with "<br>" HTML elements, or in some cases eliminated the
need for a trailing backslash.

In a few cases some unnecessary trailing backslashes inside
of a markdown code block were removed.

The following markdown files were changed in this commit:

```
1990/dds/README.md
1990/jaw/README.md
1991/ant/README.md
1991/rince/README.md
1991/westley/README.md
1992/vern/README.md
1992/westley/README.md
1998/schweikh1/README.md
2004/anonymous/README.md
2005/sykes/README.md
2006/toledo2/README.md
2011/toledo/README.md
2012/endoh2/README.md
2012/tromp/README.md
2013/robison/README.md
2015/hou/README.md
2015/howe/README.md
2015/schweikhardt/README.md
2018/burton1/README.md
2018/burton2/README.md
2018/ferguson/README.md
2018/vokes/README.md
2020/ferguson1/README.md
```

Performed `make www` to test these changes.
This commit is contained in:
Landon Curt Noll committed 2024-04-17 00:25:09 -07:00
1 parent 1785da1728
commit 4c3649a3c1
47 files changed
+481 -502

No files matched your search

+1 -1
View File
@@ -125,7 +125,7 @@ initial source is gloriously difficult to peruse. In particular, the Makefile
does:
``` <!---sh-->
sed <vern.c 's/{ /(/g;s/} /)/g;s/; /#define /' | \
sed <vern.c 's/{ /(/g;s/} /)/g;s/; /#define /' |
sed 's/} /=/g;s/{ /i/g' >vern.tmp.c
```
+1 -1
View File
@@ -235,7 +235,7 @@ at build time into much-needed text. Without this hack the program
wouldn’t pass the character limit. A nice side effect is that the
initial source is gloriously difficult to peruse. In particular, the Makefile
does:</p>
<pre><code> sed &lt;vern.c &#39;s/{ /(/g;s/} /)/g;s/; /#define /&#39; | \
<pre><code> sed &lt;vern.c &#39;s/{ /(/g;s/} /)/g;s/; /#define /&#39; |
sed &#39;s/} /=/g;s/{ /i/g&#39; &gt;vern.tmp.c</code></pre>
<p>and compiles <code>vern.tmp.c</code>.</p>
<p>Second, the rather ho-hum step has been taking of naming each variable
+12 -10
View File
@@ -150,16 +150,18 @@ is reasonably accurate.
### Here are some cities you might like to try:
- New York 41 -74\
- London 52 0\
- Moscow 56 38\
- New Delhi 29 77\
- Sydney -34 151
- Los Angeles 34 -118
- Paris 45 2
- Rio de Janeiro -23 -43
- Beijing 40 116
- Tokyo 36 140
```
New York 41 -74
London 52 0
Moscow 56 38
New Delhi 29 77
Sydney -34 151
Los Angeles 34 -118
Paris 45 2
Rio de Janeiro -23 -43
Beijing 40 116
Tokyo 36 140
```
For a domestic (US) version with higher resolution, try:
+10 -16
View File
@@ -236,22 +236,16 @@ blank line. It’s just for show, really.</p>
be just off the map; this is an unavoidable artifact. The map
is reasonably accurate.</p>
<h3 id="here-are-some-cities-you-might-like-to-try">Here are some cities you might like to try:</h3>
<ul>
<li>New York 41 -74<br />
</li>
<li>London 52 0<br />
</li>
<li>Moscow 56 38<br />
</li>
<li>New Delhi 29 77<br />
</li>
<li>Sydney -34 151</li>
<li>Los Angeles 34 -118</li>
<li>Paris 45 2</li>
<li>Rio de Janeiro -23 -43</li>
<li>Beijing 40 116</li>
<li>Tokyo 36 140</li>
</ul>
<pre><code> New York 41 -74
London 52 0
Moscow 56 38
New Delhi 29 77
Sydney -34 151
Los Angeles 34 -118
Paris 45 2
Rio de Janeiro -23 -43
Beijing 40 116
Tokyo 36 140</code></pre>
<p>For a domestic (US) version with higher resolution, try:</p>
<pre><code> main(l,a,n,d)char**a;{for(d=atoi(a[1])/2*80-atoi(a[2])-2043;
n=&quot;bnaBCOCXdBBHGYdAP[A M E R I C A].AqandkmavX|ELC}BOCd&quot;