summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorLuke Shumaker <lukeshu@lukeshu.com>2018-02-09 17:20:10 -0500
committerLuke Shumaker <lukeshu@lukeshu.com>2018-02-09 17:28:02 -0500
commit46238db12b6178ce3826665a1fea180dd28b0356 (patch)
treef316b3d748f94e18bbdb241a0387d7a23afb41de
parentc558898337b858c0fd071f06242ab94618b2a113 (diff)
Update em-dashes for pandoc > 1.8.2.1
-rw-r--r--public/java-segfault-redux.md4
-rw-r--r--public/java-segfault.md4
-rw-r--r--public/nginx-mediawiki.md2
-rw-r--r--public/term-colors.md4
4 files changed, 7 insertions, 7 deletions
diff --git a/public/java-segfault-redux.md b/public/java-segfault-redux.md
index e91dcd3..6959498 100644
--- a/public/java-segfault-redux.md
+++ b/public/java-segfault-redux.md
@@ -70,10 +70,10 @@ through all of the JVM stuff to the OpenCV code, and the OpenCV stuff
is opaque to Java debuggers.
Eventually the issue lead me back into the WPICameraExtension, then
-into WPIJavaCV--there was a native pointer being stored in a Java
+into WPIJavaCV---there was a native pointer being stored in a Java
variable; Java code called the native routine to `free()` the
structure, but then tried to feed it to another routine later. This
-lead to difficulty again--tracking objects with Java debuggers was
+lead to difficulty again---tracking objects with Java debuggers was
hard because they don't expect the program to suddenly segfault; it's
Java code, Java doesn't segfault, it throws exceptions!
diff --git a/public/java-segfault.md b/public/java-segfault.md
index 7a2d4c3..fbffb52 100644
--- a/public/java-segfault.md
+++ b/public/java-segfault.md
@@ -49,10 +49,10 @@ the pointers that were causing the issue, because it was hard with
native debuggers to see through all of the JVM stuff to the OpenCV
code, and the OpenCV stuff is opaque to Java debuggers.
-Eventually the issue lead me back into the Java code--there was a
+Eventually the issue lead me back into the Java code---there was a
native pointer being stored in a Java variable; Java code called the
native routine to `free()` the structure, but then tried to feed it to
-another routine later. This lead to difficulty again--tracking
+another routine later. This lead to difficulty again---tracking
objects with Java debuggers was hard because they don't expect the
program to suddenly segfault; it's Java code, Java doesn't segfault,
it throws exceptions!
diff --git a/public/nginx-mediawiki.md b/public/nginx-mediawiki.md
index 92d2d39..c450a3c 100644
--- a/public/nginx-mediawiki.md
+++ b/public/nginx-mediawiki.md
@@ -67,5 +67,5 @@ We are now using this configuration on
FastCGI caching for PHP.
The only thing I don't like about this is the `try_files /var/emtpy`
-bits--surely there is a better way to have it go to one of the `@`
+bits---surely there is a better way to have it go to one of the `@`
location blocks, but I couldn't figure it out.
diff --git a/public/term-colors.md b/public/term-colors.md
index 47c583a..1682484 100644
--- a/public/term-colors.md
+++ b/public/term-colors.md
@@ -23,7 +23,7 @@ is a subset of the 256 color scheme, but I'm not sure.
**8 colors: (actually 9)**
First we had 8 colors (9 with "default", which doesn't have to be one
of the 8). These are always roughly the same color: black, red, green,
-yellow/orange, blue, purple, cyan, and white, which are colors 0-7
+yellow/orange, blue, purple, cyan, and white, which are colors 0--7
respectively. Color 9 is default.
**16 colors: (actually 18)**
@@ -33,7 +33,7 @@ attribute. So when bright is on, you get "bright red" instead of
default").
**256 colors: (actually 274)**
-You may have noticed, colors 0-7 and 9 are used, but 8 isn't. So,
+You may have noticed, colors 0--7 and 9 are used, but 8 isn't. So,
someone decided that color 8 should put the terminal into 256 color
mode. In this mode, it reads another byte, which is an 8-bit RGB value
(2 bits for red, 2 for green, 2 for blue). The bright property has no