Page MenuHomePhabricator

Preserve whitespace more faithfully when processing %%% remarkup blocks
ClosedPublic

Authored by epriestley on Dec 12 2014, 7:21 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Sep 26, 10:43 PM
Unknown Object (File)
Thu, Sep 26, 9:05 PM
Unknown Object (File)
Thu, Sep 26, 8:26 PM
Unknown Object (File)
Thu, Sep 26, 6:08 AM
Unknown Object (File)
Wed, Sep 25, 4:05 PM
Unknown Object (File)
Wed, Sep 25, 3:47 PM
Unknown Object (File)
Sat, Sep 14, 12:25 AM
Unknown Object (File)
Fri, Sep 13, 9:46 PM

Details

Summary

This improves the output for some edge cases with %%% blocks. Notably, blocks did not emit a block-level spacing tag, so this:

%%%a%%%
%%%b%%%

...rendered on a single line.

Test Plan

Added unit tests.

Screen_Shot_2014-12-12_at_11.17.16_AM.png (822×549 px, 38 KB)

Diff Detail

Repository
rPHU libphutil
Branch
lit2
Lint
Lint Passed
Unit
Tests Passed
Build Status
Buildable 3249
Build 3255: [Placeholder Plan] Wait for 30 Seconds

Event Timeline

epriestley retitled this revision from to Preserve whitespace more faithfully when processing %%% remarkup blocks.
epriestley updated this object.
epriestley edited the test plan for this revision. (Show Details)
epriestley added a reviewer: btrahan.
epriestley added a subscriber: chasemp.
btrahan edited edge metadata.
btrahan added inline comments.
src/markup/engine/remarkup/blockrule/PhutilRemarkupLiteralBlockRule.php
6–19

Not sure if this needs to be surfaced in the user-facing remarkup documentation at all or if this is esoteric, etc. just figured i'd call it out in case you hadn't thought of that part yet.

This revision is now accepted and ready to land.Dec 12 2014, 7:25 PM

The %%% block itself is documented:

https://secure.phabricator.com/book/phabricator/article/remarkup/#literal-blocks

I think this just makes the rule behave more "naturally" (i.e., do what you'd expect it to do after reading the documentation) so I'm not specifically updating the documentation. If we see user confusion about the behavior of the rule I could make the docs more explicit, but as long as users can figure out how to do what they want after reading the docs I don't want to explain all the parser details if we don't have to.

This revision was automatically updated to reflect the committed changes.