February 03, 2018
On Saturday, 3 February 2018 at 10:57:58 UTC, Walter Bright wrote:
> You can see it in the CCODE macro used on the dlang web site source.

Hmm, indeed. I'll let a copy/pasted segment out of templates-revisited.dd speak for itself:

$(CCODE
template<class T, class U> class Bar { ... };

template<class T, class U> T foo(T t, U u) { ... }

template<class T, class U> static T abc;
)


February 03, 2018
Indeed, can't the compiler just replace every <>& with $(LT) $(GT) $(AMP) and the template would decide what to translate them to?
February 03, 2018
Looks like ddoc does support escapes:
ESCAPES=
  /&/$(AMP)/
  /</$(LT)/
  />/$(GT)/
February 03, 2018
On Saturday, 3 February 2018 at 15:54:03 UTC, Kagamin wrote:
> Looks like ddoc does support escapes:

Right, but it is only used in code blocks, not plain text/macros. (I've tried to change that in the past too, but "embedded html" is a feature not a bug.)

The --- code --- and the `code` both use ddoc's existing escape system. I'm saying ```code``` ought to use it too and THAT is reason for it to exist. It is more than just syntax - it does something macros cannot do.
February 21, 2018
Am Sun, 28 Jan 2018 10:25:33 +0000
schrieb Paolo Invernizzi <paolo.invernizzi@gmail.com>:

> On Saturday, 27 January 2018 at 18:15:04 UTC, David Gileadi wrote:
> > On 1/27/18 1:54 AM, Walter Bright wrote:
> >> On 1/27/2018 12:08 AM, Mike Parker wrote:
> >>> And here we've got someone who's not only willing to do it, but actually implementing it! We ought to run with it.
> >> 
> >> 
> >> I agreed with David to not call it Markdown support, so we do not raise false expectations. We simply implement what we need, and document it.
> >
> > To make myself plain (in case I didn't before) I strongly disagree with this approach.
> >
> > I agree with Mike et al that DDoc should support as much standard Markdown as is possible modulo conflicts with DDoc features. I'm willing to do the work (and indeed have done most of it already), and as I've explained before I believe the downsides are few and well mitigated.
> 
> +1

Mildly +1 from me too. Seems a little better to make it work as expected most of the time than to reduce the number of ways to do the same thing.

-- 
Marco

1 2 3 4 5
Next ›   Last »