bug#81661: 32.0.50; Offscreen context in show-paren-mode truncates multi-character keyword paren

On Thu, Aug 20, 2026 at 1:19 AM Eli Zaretskii <[email protected]> wrote:
>
> It would be nice if you (or someone else) could explain how Ruby mode
> sets up this keyword highlighting in show-paren-mode.  It seems that
> it customizes show-paren-data-function in some way, but I cannot find
> where that happens and what is the code of the customized function, I
> can only see its bytecode.

As Dmitry mentioned, for ruby-mode, SMIE is doing the heavy lifting.
However, I observe the same behavior in ruby-ts-mode too which uses
`treesit-show-paren-data` for the `show-paren-data-function`.

>
> I can see what you describe, but I see no such problem in c-ts-mode,
> which highlights preprocessor directives using a similar technique.
> In the c-ts-mode case I see "Matches #ifdef FOO_BAR_BAZ", which shows
> the full match, not just the first character.  So I wonder what is
> different in how ruby-mode does this, but I've hit a brick wall
> because I cannot find the code which implements this for Ruby.
>
> Regarding blink-paren-open-paren-line-string: I'm not sure your
> analysis is correct (and the c-ts-mode case seems to confirm my
> conclusion): it doesn't always assume "paren" is a single character,
> not for showing the context.  See these comments there:
>
>        ;; Show what precedes the open in its line, if anything.
>
>        ;; Show what follows the open in its line, if anything.
>
>        ;; Otherwise show the previous nonblank line,
>        ;; if there is one.
>
>        ;; There is nothing to show except the char itself.
>
> It's only in the last 2 cases that there's the 1-character assumption,
> right?

The above describes how it gathers the context around the opener.  The
first two scenarios are what describes the ruby-mode example and the
c-ts-mode example respectively.  Therefore, at least the first case is
also problematic.

If the opener beginning position is not the first non-blank character
on the line, the context will be to "show what precedes the open" from
the beginning of the line up to and including the opener (which is
assumed to be 1 character).  This is the context shown in the
ruby-mode example and causes the truncation.

If the opener beginning position is the first non-blank character on
the line, but there is "context" after it, the context will be to
"show what follows the open" from the beginning of the opener to the
end of the line.  This is the context shown in the c-ts-mode example.
Because it ends up showing from the start of the opener all the way to
the end of the line, it just happens to just work in this scenario,
since the length of the opener isn't really considered.

I typically use trace-function on blink-paren-open-paren-line-string
to get a better visualization for what it's returning.

Another hint of this 1-character assumption even with c-ts-mode is to
enable the `blink-matching-paren-highlight-offscreen` (i.e., "M-:
(setq blink-matching-paren-highlight-offscreen t)") which works with
show-paren-mode too.  This functionality is also handled by
`blink-paren-open-paren-line-string`.  This will apply a text property
to the opener shown in the echo area.  You can see that it only
applies the text property to the first character of the opener, even
for c-ts-mode.