[rfc-i] sourcecode indentation

[pkyzivat at alum.mit.edu (Paul Kyzivat)]

On 2/12/16 3:31 PM, Joe Hildebrand (jhildebr) wrote:
> After talking with Tony Hansen, I have an approach for sourcecode indentation that I think might work.  I'm not sold on whether the usefulness of this approach is worth the complexity it imparts, so if you think this is an important use case, please speak up.
>
> Remember, the new-in-v3 <sourcecode> element indents relative to its enclosing block, not relative to the left side of the page like <artwork>.
>
> The prepared XML document MUST include the correct whitespace on the left side of the code so that the code can be extracted into a file later.

The above is what we discussed, and I think it is desirable. Thinking 
about it further I realized that we may encounter some sourcecode where 
this goal may conflict with other goals.

For instance, if somebody wanted to include a Makefile as sourcecode, 
then it would *need* to include leading HT characters. Doesn't that run 
afoul of canonical format rules? Or can HT be in canonical xml as long 
as a formatter takes it out of the txt format?

> For example:
>
> <sourcecode name='paul.py' type='python'><![CDATA[
> def foo():]]></sourcecode>
>          <sourcecode name='paul.py' type='python'><![CDATA[
>    print("hello, world!")]]></sourcecode>
>
> If the whitespace in the second <sourcecode> were fiddled with, paul.py would be invalid when extracted.
>
> Therefore, an indent attribute MUST only apply to the output formats.  It could be an integer (with default 0).  Positive numbers would add that many spaces in front of each line in every output format.  Negative numbers would remove UP TO that number of spaces from the left side of every line in every output format.  So:

Are we assuming that formatters will always used monospaced fonts for 
sourcecode? If not, how big are these spaces?

> <sourcecode indent="-4">
> foo
>    bar
>      baz
> </sourcecode>
>
> Would generate:
>
> <pre class="sourcecode">
> foo
> bar
> baz
> </pre>
>
>
> In the HTML format.
>
>
> I'm open to suggestions on both the design as well as whether this is worth doing.

I'm neutral on it. With the rest of what has been discussed I don't 
personally foresee a need for this.

	Thanks,
	Paul