Alan Manuel Gloria:
> Okay, let's recap this topic.
> 
> 1.  almkglor's original proposal:
> At start-of-line, the "." character is treated as a space character
> until the first non-tab, non-space, non-"." character.  This means
> that "." can be used as indentation, and is equivalent to space for
> purposes of indentation matching.
> 
> 2.  dwheeler's current implemented proposal:
> The characters tab, space, and "." are indentation characters; "."
> loses the whitespace meaning outside of indentation.  For purposes of
> indentation matching "." in the current line must match a "." in the
> indentation of the previous line.
> 
> 3.  dwheeler's initial "." proposal
> Indentation may start with either tab, space, or any number of ".",
> and the rest of indentation is either tabs or spaces.  For purposes of
> indentation matching "." in the current line must match a "." in the
> indentation of the previous line.
> 
> 4.  dwheeler's pair-characters proposal
> The characters tab and space are indentation characters, and the "."
> character, if followed by a tab or space, is also an indentation
> character (if followed by a newline, it's not an indentation
> character).  The "." character loses its whitespace meaning outside of
> indentation.  For purposes of indentation matching "." in the current
> line must match a "." in the indentation of the previous line.

Great summary.

> My position is #1.  I could accept #2 if that's what the consensus is.
... 
> 4. I can't accept #4 because I'm not assured that it is easy to
> implement given a one-character lookahead implementation (Scheme).  I
> think that it is a significant implementation burden, in order to
> support what I consider to be minor advantages.

Clearly if it's too hard to implement then we shouldn't do it.

But I think this shouldn't be TOO bad to implement.  You're right that if we 
use ONLY lookahead we can't do it. but I don't think that should be a problem. 
In particular, in our current code, in sugar.scm's function readblock-internal, 
around where SPLIT-at-start is implemented, we could probably read in a 
potential symbol starting with period.  Once read in, if the symbol is EXACTLY 
one period and it is followed by space or tab, we could interpret the period as 
space, and recurse back to readblock-internal with an updated indent 
(interpreting the period as space).  I don't have time to try this right now, I 
have to go to work, but it looks feasible on a quick look.

So, if that's not too hard to implement, would this approach be acceptable to 
you?  It would let you use period to deal with HTML (the period as indentation 
original purpose), draw out lines (new additional purpose), allow us to use 
period-on-a-line for improper lists, and allow us to use symbols that start 
with period (but aren't period) without problems.

--- David A. Wheeler

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss

Reply via email to