GNU bug report logs -
#74415
29.4; mouse-start-end does not respect syntax-table text properties
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Sat, 04 Jan 2025 12:54:21 +0200
with message-id <86y0zqetnm.fsf <at> gnu.org>
and subject line Re: bug#74415: 29.4; mouse-start-end does not respect syntax-table text properties
has caused the debbugs.gnu.org bug report #74415,
regarding 29.4; mouse-start-end does not respect syntax-table text properties
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
74415: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=74415
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
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
[Message part 3 (message/rfc822, inline)]
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 74415 <at> debbugs.gnu.org
> 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.
This bug report was last modified 199 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.