Intent to mark Ducktype 1.0 final

Shaun McCance <shaunm at gnome.org>
Sat Mar 9 14:34:44 EST 2019

Hi all,

I plan on marking Ducktype 1.0 final soon. This would be a good time to
review the spec and make comments, because I'll be conservative about
backwards-incompatible changes in the future.

http://projectmallard.org/ducktype/1.0/

There are a few things that I wanted to add, but I've decided to punt
to Ducktype 1.1. Here's a list:


https://github.com/projectmallard/projectmallard.org/issues?q=is%3Aopen+is%3Aissue+milestone%3Aducktype%2F1.1

Sorry if your favorite feature didn't make it.

I made three fairly recent changes to the spec that you might want to
be aware of. I actually don't think they affect anybody right now.

1) I added "." to the list of characters you can escape, using "$.". A
leading period and space is a block title, so it's good to be able to
escape it.

2) I changed the indent trim rule for fences. Previously, a fence would
trim indentation from its lines up to the indent level of its first
line. This made it impossible to jump in and out of fences in the
middle of indented code.

    [code]
    def frobnicate()
    [[[
        pass # This would be at the same indent as the def
    ]]]

I changed it to trim to the indent level of the starting [[[ marker. I
think this is what most people would expect anyway.

3) I changed the comment/fence priority, sort of. The spec said that
comments took priority over fences, as in:

    [[[
    This is a fence.
    [-] This is a comment.
    ]]]

But the reference implementation did it the other way:

    [[[
    This is a fence.
    [-] This is not a comment. It's just text in the fence.
    ]]]

One of them had to change. I think there are arguments to be made
either way, but in the end, I decided to go with the second one, fence
priority, mostly because it's the same behavior as with XML comments
and CDATA.

--
Shaun