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.364% (+0.05%) 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.
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.
Applies Resyntax's own suggestion from the PR analyzer bot, which the GitHub UI couldn't apply because the suggestion range overlapped deleted lines. 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 found no issues.
2 participants
Adds linemaps to the grimoire.