Subject: bug#74415: closed (Re: bug#74415: 29.4; mouse-start-end does not respect syntax-table text properties)

From: [email-masked] (GNU bug Tracking System)
Date: Sat, 04 Jan 2025 10:55:02 +0000

Your bug report

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

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
74415: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=74415
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#74415: 29.4; mouse-start-end does not respect syntax-table text properties
From: Eli Zaretskii <[email-masked]>
To: Stefan Monnier <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Sat, 04 Jan 2025 12:54:21 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

> From: Stefan Monnier <[email-masked]>
> Cc: Eli Zaretskii <[email-masked]>,  [email-masked]
> Date: Fri, 13 Dec 2024 12:05:55 -0500
> 
> > 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)))))
> 
> I have the strong impression that this reflects the fact that the
> if+signal was a workaround which we're now replacing with an actual fix.

Evidently.  So I've now installed my changes on the master branch,
after removing the unneeded code which signals an error, and I'm
therefore closing this bug.

Subject: 29.4; mouse-start-end does not respect syntax-table text properties
From: Guillaume Brunerie <[email-masked]>
To: [email-masked]
Date: Mon, 18 Nov 2024 11:12:49 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

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