Re: [Docutils-users] Re: rendering ellipsis_

[David G. <go...@py...>]

[David Goodger]
 >> You may be opening up a big can of worms.  Once the underlying
 >> system is there, won't there be a bunch of requests for
 >> (potentially conflicting) additions?  When will it stop?

[Felix Wiemann]
 > The fact that there is one such a transformation doesn't mean we
 > will be adding anything, because there are IMO compelling reasons
 > for dash-transformation
...
 > which don't exist for the other transformations proposed in
 > alternatives.txt.

Compelling arguments could be put forth for any number of other
transformations.  docs/dev/rst/alternatives.txt doesn't list all
possible transformations, just a sampling.  I still think that once we
start down this path, it will be difficult to limit the uses of
character processing.  It will become a full-blown subsystem.  We must
be cautious.

 > (which are: monospace rendering, enterability and intuitiveness,
 > usualness in plain texts, and rather high unambiguousness),

Yes, those are compelling.  I'll change my vote to +0 (but read on).

 > Concerning the ellipsis, I'm not entirely sure if it's a good idea
 > to implement it, because it is not *that* important, sometimes the
 > transformation may be undesirable for some languages or
 > style-conventions,

Seems to me that *any* text transformation may be undesirable to
somebody, somewhere, sometime.

 > and it's not possible to escape special-cases because the logic
 > would be implemented in the LaTeX writer.

Why wouldn't the logic for ellipsis be in the parser?

 > Is escapability sufficient optionalness for you?

No.  That adds an extra burden for those people who *don't* want the
feature.  Better to make it a normally-disabled "power user" option
(or multiple options).  Then there's an expectation that the user will
know what they're getting into.

I say multiple options because there is no standard way to represent
the various dashes.  Some people use two hyphens for an em-dash (--),
some three (---).  According to `The Chicago Manual of Style`, two
hyphens is how typewritten manuscripts should represent an em-dash.
But we'd like to be able to represent an en-dash as well; 2-for-en and
3-for-em is convenient, but not universal.  Some people put spaces
around em-dashes --- like this --- and some don't---like this.
Typographically, the spaces are not correct and should be removed (at
least for common English usage---the mind boggles!).  Some people want
to distinguish em-dashes, but don't care about distinguishing between
en-dash & hyphen.

If we try to impose one set of conventions on all users, it will
inevitably conflict with someone's alternate conventions (not to
mention those who don't want any character processing at all!).  Even
if that is dismissed (reST is a markup language, after all), there are
variations in output requirements.

So these things would have to be options, and no, escaping doesn't cut
it.  Even options don't really cut it, because the processing is local
to the document, not the system on which it's being processed.  Pragma
directives would be ideal.

-- 
David Goodger <http://python.net/~goodger>