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:
1 parent
1785da1728
commit
4c3649a3c1
47 files changed
+481
-502
No files matched your search
+1
-1
@@ -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
|
||||
```
|
||||
|
||||
|
||||
@@ -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 <vern.c 's/{ /(/g;s/} /)/g;s/; /#define /' | \
|
||||
<pre><code> sed <vern.c 's/{ /(/g;s/} /)/g;s/; /#define /' |
|
||||
sed 's/} /=/g;s/{ /i/g' >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
@@ -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
@@ -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="bnaBCOCXdBBHGYdAP[A M E R I C A].AqandkmavX|ELC}BOCd"
|
||||
|
||||
Reference in new issue
Block a user