bug#81611: 31.0.90; show-paren-mode reports false mismatch

> From: Al Haji-Ali <[email protected]>
> Date: Wed, 12 Aug 2026 16:10:37 +0100
> 
> 
> Reproduction:
> 
> 1. emacs -Q --eval '(with-current-buffer "*scratch*"
>   (erase-buffer)
>   (emacs-lisp-mode)
>   (insert "\"S\" (\";\"\n)")
>   (setq blink-matching-paren-distance 9)
>   (show-paren-mode 1)
>   (goto-char (point-max))
>   (message "%S" (show-paren--default)))'
> 2. Note the mismatch on the last parenthesis.
> 3. M-x eval-expression RET (show-paren--default) RET
> 
> Expected: (10 11 5 6 nil) -- the final ")" correctly matched to the "("
> five characters before it.  The buffer is a complete, well-formed pair
> of top-level forms (a string "S" followed by the list (";")). Also, the
> value of `blink-matching-paren-distance` covers correctly balanced
> parenthesis.
> 
> Actual: (10 11 nil nil t) -- MISMATCH.
> 
> Cause: show-paren--default (paren.el) narrows the buffer to
> blink-matching-paren-distance characters around point before calling
> scan-sexps backward to find the match.  In the repro above, with
> blink-matching-paren-distance = 9, the narrowed buffer start on the "S"
> character inside the string.  The parsing then considers the content
> 
> ,----
> | S" (";"
> | )
> `----
> 
> So `S` is not in a string, the " (" is a string, `;"` is a comment and `)` is
> mismatched.
> 
> Note that repro above is a minimized illustration of a real issue that I
> noticed in some elisp files, rather than caused by a deliberately small
> `blink-matching-paren-distance`. Even with large
> `blink-matching-paren-distance`, any file large enough to trigger the
> narrowing (bigger than 2 * blink-matching-paren-distance, i.e. bigger
> than ~200,000 characters by default) will eventually have the narrowing
> land inside some string purely by coincidence, then if there's any
> string with a semicolon in in the narrowed region, parsing will be
> misaligned as it is in the repro above.
> 
> Suggested fix: Before narrowing, check syntax-ppss at the cutoff; if it
> is inside a string or comment, don't cut there -- but snap forward (or
> backward) to a position outside strings/comments.

Thanks.

I think what we do is a feature, meant to prevent searching too far
back, which could make show-paren-mode a nuisance, because we do the
search while you type.

It should be expected that narrowing the buffer could cause false
negatives.

IOW, I don't think this is a bug.  Maybe Stefan will have some
comments.