Subject: Re: bug#32851: 26.1.50; show-paren-mode disables off-screen-paren-match

From: Stefan Guath <[email-masked]>
Date: Thu, 27 Sep 2018 13:15:04 +0200

Yes, if I comment out the line "(not show-paren-mode)" in the function
blink-matching-open, I observe the same thing. During the short time that
the point is temporarily moved to the correct matching paren, the
old/previous highlighted parens are still visible. If they could be updated
before the jump rather than after, then the problem would be solved. But as
you say, that would require more changes to the code. To be honest, the
execution paths in this piece of code is not obvious to me, so I'm rather
puzzled where to begin...

On Thu, Sep 27, 2018 at 12:43 PM Eli Zaretskii <[email-masked]> wrote:

> > From: Stefan Guath <[email-masked]>
> > Date: Thu, 27 Sep 2018 11:35:06 +0200
> >
> > When show-paren-mode is enabled, the only respected setting for
> blink-matching-paren is "any other non-nil
> > value" which echos matched parens only when they are off-screen. The
> settings t, 'jump and 'jump-offscreen
> > are disabled.
> >
> > I can understand why the settings t and 'jump are disregarded since it
> would just be a redundant functionality
> > of show-paren-mode. But I don't understand why the setting
> 'jump-offscreen is disregarded. I think it's a better
> > option than "echo match off screen paren" since i) a jump (i.e. a
> scroll) gives more context than a one-liner in
> > the echo area, and ii) it's very convenient to get a semantic based
> scroll operation automatically.
>
> Did you try to remove the condition that show-paren-mode is active?
> When I try that, I see an unpleasant effect: when blink-matching-paren
> jumps off-screen, the wrong opening parenthesis is highlighted
> (although the jump is to the right place).
>
> So allowing jump-offscreen and show-paren-mode to coexist will need
> more changes than just removing the condition.
>