On Thu, Jul 19, 2012 at 6:23 AM, David A. Wheeler <dwhee...@dwheeler.com> wrote: > Alan Manuel Gloria: >> IIRC some peek-char implementations are just read-char followed by >> unread-char, with only one unread-char lookahead: so the sequence of >> peek-char followed by unread-char might cause strange errors about too >> many unread-char. > > Hmm, I'd think of that as a bug. > >> Generally, once an implementation supports both peek-char and >> unread-char without such a conflict they start supporting unlimited >> unread-char, so we might as well require that. > > No need. I'd like to minimize the implementation requirements, and Chez > Scheme (at least) only supports 1-char unread-char. > >> You know, I suspect that splitting the parser into a token scanner and >> a 0-lookahead (always consume next token) parser might actually be >> able to parse sweet-expressions. This is a much more different parser >> and requires a full reimplementation down to #-readers though. > > Perhaps. If we have to write portions of the parser, that's fine; the key is > that it has to be *implementable*, and then obviously we need a good > *implementation* for its use. > >> Otherwise, fine, #1 #2 or #4 is fine with me. > > Okay, that's good. I strongly prefer #4, so if all are okay by you, and I > have a strong preference, we have a winner. > >> Also, latest code seems to convert .-indent into spaces, is this >> deliberate? > > Yes, but that doesn't mean it should stay that way. > >> I proposed that, but only if it allowed me to draw >> something like this: >> >> let >> \ >> ....foo bar ; highlight this line >> . nitz quux >> meow >> >> Since multiple periods without intervening spaces are no longer >> allowed as indent, the utility of this punning is significantly >> reduced IMO. You can remove it if you think it gives better >> indentation-safety (i.e. convert the (cons #\space (accumulate-hspace >> port)) call to (cons #\. (accumulate-hspace port))). > > My reason to interpret period as space is to allow *vertical* highlighting of > a *range* that doesn't include the whole range: > > aa > . bb > . . cc > . . dd > . . ee > . ff > . gg > > But there are definitely advantages to cons'ing period, in particular, it'd > enforce consistency of indentation - enabling us to detect indentation > screw-ups. > > So I can be easily convinced to switch to consing period & forcing consistent > indentation. What do you think?
The example you've given feels like a subset of the highlighting examples I want to make, viz.: aa . bb .... cc . dd .... ee . ff . gg I don't see it as having as much utility as drawing horizontal lines of . in indentation area. Still, either one will do. The most common use case I see is to draw vertical lines in the indentation area so I that when I modify the code, I can get to see where I should indent to when I add another clause in a long cond for example. Support that and I'm happy. Sincerely, AmkG ------------------------------------------------------------------------------ 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
