[Pmwiki-users] Cookbook coments: flexlayout printable-page smartquotes

[John Rankin]

To summarise (see below for comments):
- quotes after numbers become primes
- hyphens between numbers become en dashes
- `- becomes an en dash (backtick hyphen)
- `' or `" continue to produce right quotes
- < ... > becomes l and r saquo
- ... becomes an ellipsis
- we disagree on quotes in monospaced text -- you want them to remain =
straight; I think they should be treated like other wiki inline markup and =
rendered curly unless enclosed in [=3D ... =3D]

JR

Much bigger problem is that lines indented with one space often used to=20
include source code snippets and other similiar information, and from my=20
point of view it does not make any sense to process quotes in there.=20

--
Depending on what else is in the line, you can again write=20
  [=3Dsource code snippet=3D]

 Well, I guess we have quite different points of view. You are suggesting =
to hold user responsible for markup, while my idea is that user should not =
worry about markup and everything should be done automatically.=20
--
Not at all -- I too expect smartquotes to just work without the user =
thinking about it. But it's not clear to me that indenting text is an =
instruction to leave quotes straight. Writing:
   this is a ''code'' snippet
causes PmWiki to render code in italics, as instructed. So:
   this is a 'code' snippet
renders the quotes as curly.

PmWiki's convention is that to override markup, you, the author, enclose =
it in [=3D ... =3D]. I think my approach is consistent with this quote =
from TextFormattingRules:

Anything placed between [=3D and =3D] is not interpreted by Pm Wiki. This =
makes it possible to easily do WikiWords that are not links and turn off =
other special formatting interpretation. The [=3D and =3D] can span =
multiple input lines, allowing effects to be applied to multiple input =
lines. For example, space+[=3D at the beginning of a line will cause the =
text up to the next =3D] to be monospace and uninterpreted by Pm Wiki (=
useful for program listings).=20

--

...

 What is more important, is monospace text. AFAIK monospace font on the =
web (or in a book) is used to quote source code snippets, computer outputs,=
 or commands user have to type in shell, or alike. In any of these cases =
there should not be done any typesetting. After all wiki engine treats =
monospace text differently -- every end-of-line is treated as <br> and so =
on. So even now typesetting is not applied to monospace text. Why should =
smartquotes be? Or let me put it this way: do you know any single case =
when user might want to use monospace font and smartquotes?

--
Not strictly true. PmWiki interprets all inline markup the same way in =
monospaced text as any other text -- ''text'', '''text''', [+text+] and so =
on. Also, your comment only applies to technical writing. Monospaced text =
has many other business applications.

--

While it could easily render [0-9]\s*- as an en dash, it may be better to =
let people write (say) `- (backtick minus) and have this render as &ndash;

 That's the same problem as above. If you force users to write `-, how =
many people will do it? On the other hand if you will do /(\d)-(\d)/\1&=
ndash;\2/ how many dashes would be incorrectly converted to en dashes? I =
would say none.



Thus one would write: the meeting is from 1`-3 (en dash) but half-baked =
for a normal hyphen.

My understanding is that strictly, an en dash means 'to' so 1 en dash 3 =
means 1 to 3, whereas 1 - 3 means 1 minus 3.=20
 That's interesting. Never heard of such interpretation of en dash :). =
What is in your opinion a correct symbol for minus?=20
--
Well... See The Elements of Typographic Style by Robert Bringhurst (second =
edition) pp80-81. In full there is (you are going to be sorry you asked!)
hyphen
en dash (M/2)
em dash
subtraction sign
figure dash (width of a numeral)
three-quarter em dash
three-to-em dash (M/3)

To quote Bringhurst, "use close-set en dashes ... to indicate a range"
--

...

 In any case, how many people writing wiki pages aware of all these tricky =
details? Suppose `- is the only way to create an en-dash, how many people =
will ever use it? I would argue that my approach will increase quality of =
the pages way more then yours. It still would not hurt having `-, so that =
those who want explicitely tell that something is en dash could do that, =
but \d-\d should take care of the bulk of en dashes.

--
So your proposal is that, in the absence of an HTML subtraction sign or =
figure dash, we use the &ndash; entity. OK, but you also need `- to take =
care of the Wellington-Picton case.
--

...

And where does it stop? ... could becomes &hellip; so the dots never break =
across a line, and so on.
 That also would be nice.