bug#74415: 29.4; mouse-start-end does not respect syntax-table text properties

[Guillaume Brunerie <guillaume.brunerie@gmail.com>]

Den lör 7 dec. 2024 kl 13:33 skrev Eli Zaretskii <eliz@gnu.org>:
>
> > From: Guillaume Brunerie <guillaume.brunerie@gmail.com>
> > Date: Thu, 5 Dec 2024 07:13:20 +0100
> > Cc: Stefan Monnier <monnier@iro.umontreal.ca>, 74415@debbugs.gnu.org
> >
> > Den tors 28 nov. 2024 kl 17:02 skrev Eli Zaretskii <eliz@gnu.org>:
> > > Thanks.  Guillaume, does the patch below give good results?
> >
> > Thank you, I haven’t managed to apply the patch locally yet but I
> > think that would work (I’m on Emacs 29.4, but I guess I might need to
> > get the development version of Emacs? The patch seems to fail on my
> > mouse.el).
> > But one thing I want to point out is that the two `(signal 'scan-error
> > [...])` seem to be dead code now, as they test the exact opposite of
> > what the previous test now does.
>
> Sorry, I don't understand.  The changes I proposed didn't touch the
> lines that signals errors.  Are you saying that those errors were dead
> code before these changes as well?  If not, could you please elaborate
> on the issues you see with the changes I proposed?

No, it was not dead code before, but changing the outer condition
makes it impossible for both the outer condition and the inner
condition to be true at the same time.
The current code is the following (inside a cond)

((and (= mode 1)
      (= start end)
      (char-after start)
      (= (char-syntax (char-after start)) ?\())
 (if (/= (syntax-class (syntax-after start)) 4) ; raw syntax code for ?\(
     ;; This happens in CC Mode when unbalanced parens in CPP
     ;; constructs are given punctuation syntax with
     ;; syntax-table text properties.  (2016-02-21).
     (signal 'scan-error (list "Containing expression ends prematurely"
                               start start))
   (list start
         (save-excursion
           (goto-char start)
           (forward-sexp 1)
           (point)))))

So the 'scan-error happens when the character is a parenthesis
character according to the syntax table (that's what is tested by (=
(char-syntax (char-after start)) ?\()) but has a text property telling
Emacs to treat it as something else than a parenthesis instead.
Changing the "char-syntax" test to (= (syntax-class-to-char
(syntax-class (syntax-after start))) ?\()) makes it so that the
'scan-error happens if the character is both a parenthesis and not a
parenthesis according to text properties, which is not possible.

In other words, it is not possible for both (= (syntax-class-to-char
(syntax-class (syntax-after start))) ?\()) and (/= (syntax-class
(syntax-after start)) 4) to be simultaneously true, as they are the
exact opposite of each other, so when they are nested conditions, the
inner one becomes dead code.

That said, it only seems to happen in rare edge cases (as in
https://lists.gnu.org/archive/html/bug-gnu-emacs/2016-02/msg00988.html),
as regular unmatched parentheses do seem to still trigger a different
"Unbalanced parentheses" scan error.

Apart from that, I have now managed to test the patch, and I can
confirm that it fixes my original issue