Document linemaps in the grimoire#809
Conversation
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The linemap-lines contract has always promised immutable strings, but the implementation built lines with substring, which returns mutable ones. Any use of linemap-lines through the contract boundary raised a broke-its-own- contract error. It has no callers outside the module, so nothing noticed. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Docs preview: https://resyntax.notjack.space/preview/809/ |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Resyntax analyzed 4 files in this pull request and found no issues.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
There was a problem hiding this comment.
Resyntax analyzed 4 files in this pull request and found no issues.
|
coverage: 95.362% (+0.04%) from 95.319% — grimoire-linemap into master |
Linemaps are built from strings, and Racket string APIs (and Resyntax's string replacements) index characters from zero. One-indexed positions are a file port and IDE convention that doesn't belong here. Line numbers stay one-indexed, since they're primarily useful in UI contexts. Every caller was converting with add1/sub1 at the boundary; those shims are now gone, and syntax-line-range converts from one-indexed syntax positions itself. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
There was a problem hiding this comment.
Resyntax analyzed 4 files in this pull request and has added suggestions.
There was a problem hiding this comment.
Resyntax analyzed 4 files in this pull request and has added suggestions.
Previously only the port-reading path normalized newlines, so two string sources could be non-equal? yet denote the same text via source->string. Normalizing eagerly in the struct guards removes that corner case as early in the data flow as possible. The guard conversion matches the full set of sequences that reencode-input-port converts, verified empirically: \r\n, \r NEL, \r, NEL, and LS all become \n. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Rather than a regexp that reproduces the port's conversion behavior, round- trip the string through an actual newline-converting reencoded port. Slightly more copying, but it can never fall out of sync with what reading a source does. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
There was a problem hiding this comment.
Resyntax analyzed 5 files in this pull request and has added suggestions.
There was a problem hiding this comment.
Resyntax analyzed 5 files in this pull request and has added suggestions.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
There was a problem hiding this comment.
Resyntax analyzed 5 files in this pull request and has added suggestions.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
There was a problem hiding this comment.
Resyntax analyzed 5 files in this pull request and has added suggestions.
2 participants
Adds linemaps to the grimoire.