Fix IDE keyword-match underlining at end-of-line and on multi-byte lines - #393
Open
fantaisie-software wants to merge 1 commit into
Open
fantaisie-software wants to merge 1 commit into
fantaisie-software wants to merge 1 commit into
Conversation
Reported at https://www.purebasic.fr/english/viewtopic.php?t=82666: the matching-keyword underline in the code editor fails to appear when the caret sits right after the last character of a line, and is misplaced on lines containing multi-byte UTF-8 characters (e.g. non-Latin text). - GetWordBoundary() rejected any caret position equal to the line's length (Mode=0), even though the character-scan logic right below it already handles running off the end of the buffer correctly (as it does for Mode=1/autocomplete). Relaxed the guard to allow Position <= BufferLength, mirroring Mode=1. Applied identically to the duplicate copy in PureBasicDebugger/Standalone_ScintillaStuff.pb per the "keep in sync" comment on both copies. - UpdateKeywordHighlight() used StartIndex/EndIndex (character offsets from GetWordBoundary(), UTF-16 code units) directly as Scintilla byte offsets when marking the keyword under the caret, instead of converting them like every other lookup in the function does. On a line with multi-byte UTF-8 characters before the keyword this misplaced the underline. Now uses *OriginalItem's already-correct byte-based Position/Length instead, consistent with how every other matched item is highlighted. - JumpToMatchingKeyword() had the same byte/char mismatch comparing a parser item's byte Position against a char-based EndIndex; fixed by converting EndIndex to a byte offset first. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes two related bugs in the IDE editor's matching-keyword underlining, reported at https://www.purebasic.fr/english/viewtopic.php?t=82666 ("PB 6.03 - not work marking of matching keywords"):
EndIfat the very end of a line/file).Changes
GetWordBoundary()(HighlightingFunctions.pb, and its duplicate inPureBasicDebugger/Standalone_ScintillaStuff.pb, kept in sync per the existing "report to the IDE/standalone debugger" comment on both copies): relaxed theMode=0guard fromPosition < BufferLengthtoPosition <= BufferLength, matching the leniency already given toMode=1(autocomplete). The character-scanning logic below the guard already handles running off the end of the line correctly; it just wasn't being allowed to run for this caret position.UpdateKeywordHighlight()(ScintillaHighlighting.pb): the "mark the original item" step usedStartIndex/EndIndex— character offsets fromGetWordBoundary()— directly as Scintilla byte offsets, instead of converting them like every other lookup in the function does. Now uses*OriginalItem's already-correct byte-basedPosition/Length, consistent with how every other matched/mismatched item is highlighted in the same function.JumpToMatchingKeyword()(ScintillaHighlighting.pb): same byte/char mismatch, comparing a parser item's bytePositionagainst a char-basedEndIndex. Fixed by convertingEndIndexto a byte offset viaCharsToBytes()first.Test plan
pbcompiler /CHECK /THREADonPureBasicIDE/PureBasic.pb— clean./EXEbuild of the IDE succeeds.EndIfat EOL) now underlines the matching keyword, matching the behavior when the caret is one position earlier.🤖 Generated with Claude Code