Skip to content

Fix IDE keyword-match underlining at end-of-line and on multi-byte lines - #393

Open
fantaisie-software wants to merge 1 commit into
develfrom
fix/ide-keyword-highlight-eol-and-multibyte
Open

fantaisie-software wants to merge 1 commit into
develfrom
fix/ide-keyword-highlight-eol-and-multibyte

Conversation

@fantaisie-software

Copy link
Copy Markdown
Owner

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"):

  • The underline failed to appear when the caret sat right after the last character of a line (e.g. right after EndIf at the very end of a line/file).
  • The underline was misplaced on lines containing multi-byte UTF-8 characters (e.g. non-Latin text), because a character offset was used directly as a Scintilla byte offset without conversion.

Changes

  • GetWordBoundary() (HighlightingFunctions.pb, and its duplicate in PureBasicDebugger/Standalone_ScintillaStuff.pb, kept in sync per the existing "report to the IDE/standalone debugger" comment on both copies): relaxed the Mode=0 guard from Position < BufferLength to Position <= BufferLength, matching the leniency already given to Mode=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 used StartIndex/EndIndex — character offsets from GetWordBoundary() — directly as Scintilla byte offsets, instead of converting them like every other lookup in the function does. Now uses *OriginalItem's already-correct byte-based Position/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 byte Position against a char-based EndIndex. Fixed by converting EndIndex to a byte offset via CharsToBytes() first.

Test plan

  • pbcompiler /CHECK /THREAD on PureBasicIDE/PureBasic.pb — clean.
  • Full /EXE build of the IDE succeeds.
  • Manually verified in the built IDE: placing the caret immediately after the last character of a line (e.g. after EndIf at EOL) now underlines the matching keyword, matching the behavior when the caret is one position earlier.

🤖 Generated with Claude Code

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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant