Intent to mark Ducktype 1.0 final
Shaun McCance
<shaunm at gnome.org>
Sat Mar 9 14:34:44 EST 2019
- Next message: MEP: Shorthand syntax for guiseq and keyseq
- Sort by: [ thread ] [ subject ] [ author ] [ date ]
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