On Sat, Nov 10, 2007 at 05:08:11PM +1100, Steve Bennett wrote:
On 11/10/07, Jay R. Ashworth jra@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