|
From: David T. <dv...@da...> - 2005-06-06 21:08:20
|
>> is it your reading of the specification that writing the #\Tab >> character to the output stream determinately keeps the output-stream >> at >> the start of a line? > > No. But any other value would be just as wrong. 8 would be wrong on > Windows, > 4 or 2 would be wrong on Unix. And it depends on the settings of the > terminal > (xterm or so). > > FRESH-LINE just tests the whether the value is 0. But the > pretty-printer > is highly interested in the magnitude, and since you cannot get this > right, > it doesn't really matter what FRESH-LINE does in this context. I do not advocate computing the offset when the tabulation character is written to the output. But fresh-line should NOT look at line-column at all; instead, it should look at a bit that indicates that the line is not at its start, and #\Tab should be among characters that set the bit. > I'd recommend to just avoid the tabs. FORMAT ~nT outputs enough spaces > to > get to column n; therefore you don't need tabs. If CLISP supports recognizes #\Tab, it should handle it in accordance with specification. The question is not whether something is good or bad; but whether FRESH-LINE is conforming or not. I believe that CLISP's fresh-line implementation is not conforming. Imagine, I deal with a text format that uses #\Tab to denote indentation levels; spaces are a part of content and do not count. Therefore, I do need tabulation characters. But this is not important, what I am trying to say is that FRESH-LINE in CLISP does not conform to the Common Lisp specification, because it does not output #\Newline on fresh-line when it cannot determine whether the stream is at the start position of a line. A useful approach would be to set it char_width to -1, and to not increment it when it is -1, meaning that the position cannot be determined. Another way is to allocate a separate bit field just to mark that a line is 'dirty' (and I am not sure that the latter is cleaner than the former). David Tolpin |