Inline code spans still get emphasis applied: `The_brown_fox` renders "brown" italic

[jasonzondor]

Description

Text inside an inline code span (wrapped in backticks) still has Markdown emphasis applied to it. If the code span contains underscores or asterisks that form an emphasis pair, the enclosed text is rendered italic/bold even though it's inside code.

Steps to reproduce

1. Type `The_brown_fox` into the editor.
2. Observe that "brown" is rendered in italics.

Other examples that misbehave:

• `a_b_c` → b italic
• `foo**bar**baz` → bar bold
• `see [x](y)` → link styling applied inside the code span

Expected

Inside an inline code span, all other inline Markdown (emphasis, strong, links) should be inert. Only the monospace/code styling should apply.

Cause

In src/markdownhighlighter.cpp, highlightInline() first formats inline code spans via the `([^`]+)` regex, then unconditionally runs inlineMarkup(text) over the entire line and re-applies bold/italic/link formats. The emphasis/link passes have no awareness of the code-span ranges found earlier, so any _, *, or [...]() sitting inside backticks is still matched and its setFormat() overrides the code format for the enclosed content.

Suggested fix

Compute the inline code-span ranges first, then skip any InlineMarkup item from inlineMarkup() whose span overlaps a code-span range (or mask backtick-delimited regions out of the string before running the emphasis/link regexes).

[omarchybot]

Confirmed in source, and your stated cause is right in full: highlightInline() applies the code format first, then runs inlineMarkup() over the whole line with no awareness of the code ranges, and the later setFormat calls replace the code format rather than merging with it. All four of your examples reproduce. There is a second symptom you did not mention — inlineMarkup() also feeds Backend::hiddenRangesAt, so the arrow keys skip over the literal underscores and brackets inside the code span as if they were hidden markers.

Your PR #48 is under review and is the fix; I have commented there in detail. In short, the approach is right and I pushed two commits to it: the overlap test also discarded emphasis and links that merely enclose a code span, which broke _a `b` c_ and [see `code`](url) — cases that worked before the branch — and once those were restored the code pass had to move after the emphasis pass so a code span keeps its own styling where emphasis wraps it.

Checked by Claude Opus 5 and by Codex at xhigh reasoning as an independent second opinion; Codex confirmed the mechanism and the caret symptom from the source. Waiting on the maintainer now, since merging is their call.