On Sat, Nov 10, 2007 at 05:08:11PM +1100, Steve Bennett wrote:
On 11/10/07, Jay R. Ashworth <jra(a)baylink.com>
wrote:
Or, and here's an idea I don't see much,
we could define **bold** and
//italics// as *additional* ways to punctuate such things, and keep the
old ones until they wither and die.
L'//arc de Triompe// would be *entirely* unambiguous.
And wrong :) You mean L'**arc de Triomphe**. It's an appealing idea (and
certainly // and ** is better than '' and ''') but means the parser
passes
through an even more complex phase.
It's *bold*?
(As I continue
to note, any extended syntax in this specific area
should track historical usage as closely as possible to comply with the
Principle of Least Surprise.)
I don't think the principle of least surprise even comes into it. You
can't change syntax overnight for far more pragmatic reasons, like you
simply can't train everyone on the new syntax fast enough. Principle
or no principle.
Not my point. You're discussing speed of cut, I'm discussing *target*
of cut.
It shouldn't be all *that* hard to instrument the
parser to flag such
constructs and put them in extra columns or a
parallel table.
Make analytical work a lot easier, too.
I'm not sure which constructs you're talking about? Why do you need to
flag ** and //?
My assertion was that, for analytical purposes, if it was practical to
run it, we could instrument the parser to log somewhere the count of
constructs it parses on each page, which would save grinding the entire
database to get the statistics of which I speak. The users would grin
it for us.
Cheers,
-- jra
--
Jay R. Ashworth Baylink jra(a)baylink.com
Designer The Things I Think RFC 2100
Ashworth & Associates
http://baylink.pitas.com '87 e24
St Petersburg FL USA
http://photo.imageinc.us +1 727 647 1274