[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: making indentation marker &| implicit
On 05/27/2013 06:39 PM, Alex Shinn wrote:
On Tue, May 28, 2013 at 10:09 AM, Per Bothner <per@xxxxxxxxxxx
... 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
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
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.