GoldenDict-ng Fixes a Full-Text Search Freeze Caused by Unpaired Quotes

Quick Answer

GoldenDict-ng could freeze after a full-text search returned results because its highlighting-keyword scanner could stop at an unmatched quote without moving past it. The surrounding loop could then revisit the same character indefinitely. The correction changes how that scanner handles unmatched apostrophes and double quotes; it does not change dictionary indexing or query matching.

The v26.11.0 GitHub release, published October 23, 2026, lists the fix. PR #3117 was merged into the staged branch on October 22. That establishes the merge and release-note inclusion, but not delivery through every downstream package channel.

In Plain English

GoldenDict-ng’s official full-text-search documentation describes searching words or sentences inside dictionary article text, including material outside headwords, within the current dictionary group. Finding an article and preparing its highlighted words are distinct parts of the experience.

That distinction matters in issue #3115. The reporter said the search found results, but the application froze after an article was opened, while highlighting was being prepared. The report identifies both single apostrophes and double quotes and supplies an Ancient Greek reproduction query. This is the reporter’s account, not an independently reproduced application test.

A quote can have different roles in a search string. It can begin a complete quoted phrase, or it can appear without a matching partner. The highlighting parser needs to decide whether the character belongs to a phrase, belongs inside an ordinary token, or should be omitted. Before this correction, its phrase handling and ordinary-token handling could leave an unmatched quote between those decisions: neither path consumed it.

Code Evidence

The affected function is RX::Ftx::processSearchStringForHighlight in src/common/globalregex.cc. Commit a418b02 changes that one source file, with 20 additions and three deletions.

Before: stopping without consuming

In the parent version, the function first handled complete quoted phrases. Its bare-token scan then stopped at whitespace or either quote character. If the current quote did not begin a complete phrase, that scan could stop immediately, leaving the scan position unchanged.

The following is an editorial control-flow summary, not copied C++ or an executable replacement:

Before, on the unmatched-quote path:
  complete phrase is not recognized
  bare-token scan stops at the quote
  scan position remains unchanged
  outer scan meets the same quote again

The failure is therefore more specific than “quotes are difficult to parse.” A loop can revisit the same input when an inner scan stops on a delimiter and no surrounding branch takes responsibility for advancing beyond it. Here, the parent source and the maintainer’s explanation identify that missing forward progress at an unmatched quote.

Control-flow comparison: the old scan returns to an unmatched quote; the corrected scan consumes it, while complete phrases keep their existing handler. — Illustration of the code change: unmatched quotes now advance the scan; complete quoted phrases retain their existing handling.

After: inspect the quote and advance when unmatched

The updated function examines quote characters during token scanning. When a quote begins a complete phrase, it leaves that phrase for the existing phrase-handling path. When the quote is unmatched, it consumes the character so the scan can continue.

Consumption and keyword content are separate decisions. An unmatched quote following token text is retained in the highlighting keyword. An unmatched quote at the beginning of a token is omitted. This preserves the distinction between punctuation attached to text and an unmatched opening delimiter.

After, summarized:
  quote begins a complete phrase:
    leave it for the existing phrase handler
  quote is unmatched after token text:
    consume it and retain it in the token
  quote is unmatched at token start:
    consume it and omit it from the token

The PR’s expected keyword results cover the behavioral distinction: an apostrophe in an elided Greek token is retained, a quote inside a token is retained, and unmatched quotes beginning a token are omitted. The PR says keyword behavior was checked for algorithm equivalence outside the application. That supports the stated token treatment, while leaving application-level regression coverage as a separate question.

Why It Matters

The practical lesson is about progress through input. Recognizing a delimiter is only part of a parser’s work; the control flow must also decide which path consumes it. In this case, the old bare-token scan correctly recognized a quote as a stopping point, but the unmatched-quote path could leave the outer scan pointing at that same character.

Our editorial reading is that the boundary between phrase recognition and token scanning is the useful engineering detail. The correction gives unmatched quotes explicit treatment while retaining the existing path for complete phrases. It also explains why “remove all quotes” would be an inaccurate description of the patch: some quote characters remain part of the resulting highlighting keywords.

The reported sequence also helps locate the fault. A search returning results does not establish that all later article-view work will finish. Here, the issue describes a freeze after result discovery, and the changed function extracts highlighting keywords. Those facts support a focused explanation of the highlighting path; they do not support claims that the search engine, indexing, or result correctness was repaired.

An Open Question

Will a future automated regression test exercise both unmatched apostrophes and unmatched double quotes through the actual article-highlighting path?

The reviewed evidence does not establish that such coverage exists. A test that opens a result and exercises highlighting with both quote types would address the gap between checking keyword behavior outside the application and checking the user-visible path described in the issue. It would need to establish that the operation completes and that the intended keyword treatment is preserved.

Scope and Limitations

The observed code change concerns this quote-handling path in the highlighting-keyword function. It is not evidence of a general guarantee for every malformed query or every loop in the parser. The issue’s GUI freeze remains a user-reported reproduction in this research; no independent GUI reproduction or application-level regression run is claimed here.

The PR page reports 14 of 15 checks passed and shows a failed SonarCloud maintainability quality gate. It would therefore be inaccurate to describe the checks as all passing. The supplied evidence does not establish what that failed gate means for the application’s runtime behavior.

Release availability also has a defined boundary. The GitHub release notes for v26.11.0 include PR #3117 and commit a418b02. They confirm the fix is listed in that published release; downstream package publication and delivery to individual installations were not checked. No timing measurements, benchmark gains, or platform-wide rollout claims follow from this evidence.