Re: Cookbook coments: flexlayout printable-page smartquotes

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 [= ... =]

JR

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

--
Depending on what else is in the line, you can again write 
  [=source code snippet=]

 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. 
--
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 
[= ... =]. I think my approach is consistent with this quote from 
TextFormattingRules:

Anything placed between [= and =] 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 [= and =] can span multiple input lines, 
allowing effects to be applied to multiple input lines. For example, space+[= 
at the beginning of a line will cause the text up to the next =] to be 
monospace and uninterpreted by Pm Wiki (useful for program listings). 

--

...

 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. 
 That's interesting. Never heard of such interpretation of en dash :). What is 
in your opinion a correct symbol for minus? 
--
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.