libera/#climacs - IRC Chatlog
Search
10:03:47
scymtym
beach: your analysis was correct. the problem is that cached errors result in repeated :SKIP return values without progress in terms of stream position. my fix was to turn cached errors into :EOF iff the contained condition is an END-OF-FILE error
10:03:57
scymtym
that fix solves the ('<newline> problem but i experimented some more and found that (#'<newline> is still an issue
10:05:40
scymtym
the common theme is that the we repeatedly look up and process the same error result without advancing the stream position
11:09:52
scymtym
there is some complexity to this: if we start with (#<cursor><newline><eof> , there is an error "newline is not a valid sub-character error" in the cache at 1:0 (line 1, item 0). if we type ' at <cursor> we get (#'<cursor><newline><eof>. then, after reading (#' we want to read a function name using a recursive READ, we skip over the <newline> and get the cached error which is no longer correct due to the changes to the input preceding
11:11:30
scymtym
(and unrelatedly, typing "#::foo" results in an error condition without source information for some reason)
14:02:38
scymtym
i have a hunch that similar issues could come up in non-error situations like changing #(:a 1 :b 2) to #_(:a 1 :b 2). i can imagine reader macros that would require (:a 1 :b 2) to be read again instead of being taken from the cache. but i haven't done any experiments
14:04:58
beach
But it sounds strange to me. After all, we cache calls to READ, so if READ is called again at the same buffer position, the cache ought to be valid.
14:06:30
scymtym
i thought the #_ reader macro could change the current readtable or bind reader variables
14:08:48
beach
Take care. For when you come back: I think all we can hope for in such situations is to not have an error signaled by Second Climacs and to not go into an infinite loop. But the result may be incorrect.
14:20:45
splittist
If I'm typing in a bunch of text cases for the #_ reader macro I'm about to define, am I expecting to see a bunch of error indicators that will eventually disappear as I progressively add more correct versions of the macro to the image?
14:21:45
beach
I guess so. I haven't thought through such use cases. But I will try to do that. But not today.
15:18:52
beach
I made great progress on FILL-PARAGRAPH (for line comments) today. Given a cursor position, I can identify all the wads that are involved in the operation, both at the top level and nested inside an expression.
15:19:42
beach
Next step is to rearrange the words in those comments. That's also not trivial, but I think I know what to do. The most tricky part is to leave the cursor in a reasonable place.
15:21:35
beach
If the cursor was sufficiently far to the left, it should be left intact. If not, it should preserve its place in the text.