Improving ddoc

[Adam D. Ruppe via Digitalmars-d]

On Thursday, 1 January 2015 at 11:33:25 UTC, Walter Bright wrote:
> Ddoc assumes ( ) nests. But this would require that these 
> characters nest, too:
>
>    *abc_def * _i
>
> for example, which is stretching things a bit because they do 
> not naturally nest.

I think someone who writes *long bold text

like this*

is in error anyway; I lose track of what those stars are supposed 
to me. (BTW the gmail html to text converter does this, making 
emails unreadable to me!)


I would say the pattern to match would be \w\*[a-zA-Z0-9]+\*\w.


Honestly, I think _foo_ and /foo/ are both not worth supporting 
in this context. *bold* is the only one we really need - the most 
common, and the least ambiguous.

We do NOT want it to think *a = *b; is supposed to be bolding. We 
do NOT want it to think _object._method is supposed to be 
underlined. We do NOT want it to think /bin/bash is supposed to 
be italic. (Granted, those might be in code blocks anyway, but 
still, no point making this harder than it has to be.)

But when would you write *a* = foo in code? Never, I don't think 
that's ever valid. So making that a $(STARRED) macro should just 
work in pretty much all circumstances.


And we can always fall back on $(B bold) and $(I italic) when we 
do need them.




I just think shooting for an 80% solution is more reasonable than 
a 99 or 100% solution - just do the easiest, least ambiguous 
shortcuts and use macros for the rest of them. It'll probably go 
a LONG way.

Again those are: *bold* and `code`.