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

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

Hello,

The `mouse-start-end` function (used in particular when double clicking on an
opening parenthesis to select the region from that opening parenthesis to the
matching closing parenthesis) does not respect syntax-table text properties to
determine if the character at point is an opening parenthesis. Looking at the
code, it is at line 1941 in lisp/mouse.el (and there are more instances further
down in the same file)
(https://github.com/emacs-mirror/emacs/blob/eee0ed8442aa78320a3e578ab290df145fb49624/lisp/mouse.el#L1941):

    ((and (= mode 1)
          (= start end)
          (char-after start)
          (= (char-syntax (char-after start)) ?\())

Note that the documentation of `char-syntax` says:

> If you’re trying to determine the syntax of characters in the buffer, this is
> probably the wrong function to use, because it can’t take ‘syntax-table’ text
> properties into account. Consider using ‘syntax-after’ instead.

The line just below does use `syntax-after`, but it looks like something that
was added later to work around a related bug. I think this function should be
refactored to only use `syntax-after` instead of `char-syntax`.

For context, I'm writing my own Typescript major mode where the < and > symbols
are sometimes balanced delimiters, sometimes not (determined via Tree-sitter). I
could get most things working using syntax-table text properties, like
forward-sexp and show-paren-mode, but not double-click selection due to this
issue.

Related: https://lists.gnu.org/archive/html/bug-gnu-emacs/2016-02/msg00988.html
In that issue, the opposite problem occurred, double clicking on an unmatched
open parenthesis did not take into account the "punctuation" text property. But
the fix only fixed one half of the issue (when a text property makes a
parenthesis into not a parenthesis) and I am facing the other half (a text
property makes a punctuation character into a parenthesis).

Best,
Guillaume