Re: making indentation marker &| implicit Per Bothner 28 May 2013 07:19 UTC

On 05/27/2013 06:39 PM, Alex Shinn wrote:
> On Tue, May 28, 2013 at 10:09 AM, Per Bothner <
> <>> wrote:

>     ... Scribble avoids this in a way that seems nicer:
>     Any indentation that is common to each line
>    (following a newline) is stripped.
> This is the part that always bothered me, and why I didn't
> implement indentation removal.  Many of the examples are
> unintuitive, and the rule itself does not seem to be consistent.
> For example, the docs have
> @foo{bar
>    baz
>    bbb}
> reads as
> (foo "bar""\n"
>      "baz""\n"
>      "bbb")
> Why?  The indentation of the leading bar is deeper in the
> source port than the following lines, yet shallower in the
> string.  How does it get the same result indentation?

I agree - it is rather "magic".
My guess is they wanted to support the following two styles:




and so tried to define rules to support those.



doesn't really make sense.

> Unsure of the right semantics, it seemed simpler to leave
> this out since it's easy enough to specify arbitrary trimming
> behavior separately:
> @trim{@foo{
>    ...
> }}

Well, that becomes tedious if you have to do it often.

>     Tabs would have to be consistent: If a line starts with
>     T1 tabs followed by S1 spaces, and another line starts with
>     T2 tabs followed by S2 spaces, then it is an error if
>     (and (not (= T1 T2)) (> S1 0) (> S2 0)).
> I presume you mean not an error, just not the same indentation?

I mean an error - it indicates ambiguous use of TABs.

> ... alternately just define a tab as 8 spaces.

That is fine in a Unix-based culture.  Some programming
cultures use TAB to mean "indentation unit", which can
be set according to user preference.  I.e. TAB is a
flexible user-settable length.  Thus if you use TABS
inconsistently the indentation is ambiguous, and I thin
at least deserves a warning.
	--Per Bothner