From: Alan Mackenzie <acm@muc.de>
To: Andrew Hyatt <ahyatt@gmail.com>
Cc: David Reitter <david.reitter@gmail.com>, 5560@debbugs.gnu.org
Subject: bug#5560: 23.1.92; parens matching in c-mode broken
Date: Sat, 20 Feb 2016 22:57:23 +0000 [thread overview]
Message-ID: <20160220225723.GA10801@acm.fritz.box> (raw)
In-Reply-To: <m2wpq4xa4t.fsf@gmail.com>
Hello, David and Andrew.
On Tue, Feb 16, 2016 at 10:56:34PM -0500, Andrew Hyatt wrote:
> I can confirm this still doesn't work right in Emacs 25. However, I get
> a slightly different experience, with clicking on all 3 left parens
> highlighting until the first right paren only. Similarly, that right
> paren seems to be the matching paren for all 3 left parens.
What is (now) happening is this: the C Preprocessor construct ends at the
end of the second line (due to the space after the \ there). The first
two open parentheses on that line are unmatched. In such circumstances,
CC Mode splats the syntax of such characters by setting syntax-table text
properties on them. This is to prevent them spuriously matching parens
outside the CPP construct.
When you double click on one of the non-matching parens, the critical
piece of code reached is in `mouse-start-end'. Instead of checking the
syntax of the character in its context (i.e. respecting syntax-table text
properties), it simply checks the syntax of the bare character '(', and
finds it's an open paren. It then does (forward-sexp) to try and find the
matching ')'. This ignores the two "dummy" parens and then scans over
the real paren pair remaining.
One solution would be to replace the (obsolete) form in mouse.el:
(char-syntax (char-after start))
with the modern (and correct) form
(syntax-after start)
. A small problem with this is that `syntax-after' returns a cons of raw
numbers rather than the more picturesque character descriptors like ?\(.
A bigger problem is that there are still approximately 164 uses of
`char-syntax' in our sources, all (or most) of which need superseding by
`syntax-after'.
If this were to be done, double clicking on one of these unmatched parens
would attempt to match the "word it is in". I don't know exactly what
would happen. Probably not very much. In fact, I'm going to try it. (A
bit later): Double clicking on a "dummy paren" would mark the sequence of
three parens. I think this is better than marking up to the single close
paren, but not by much.
> David Reitter <david.reitter@gmail.com> writes:
> > Parens matching in C mode is sometimes surprising. In the example
> > below, double-clicking on either of the first two opening parentheses
> > will mark the text until the " hyper_modifier : 0)", but that is correct
> > only for the second paren, while the first one is unmatched due to a space
> > following the backslash.
> > #define EV_MODIFIERS(e) \
> > ((([e modifierFlags] & NSHelpKeyMask) ? \
> > hyper_modifier : 0) \
> > ...
> > It would be more useful if an "unmatched parentheses" was shown, or
> > if the region up to the end of the scan process (i.e. the
> > space+newline) was marked.
Giving a decent error message here would be difficult. We're down in the
depths of the mouse code, but the strategem of giving syntax-table text
properties to parentheses is a pure CC Mode one. Signaling an error if
a paren has other than paren syntax is liable to have unforseen side
effects somewhere, somehow, some time.
Do you (plural) think it is worth while fixing the mouse code, as
detailed above, or do you have any other ideas for a fix?
> > In GNU Emacs 23.1.92.86 (x86_64-apple-darwin10.2.0, NS apple-appkit-1038.25)
> > of 2010-02-08 on scarlett.local - Aquamacs Distribution 2.0dev
> > Windowing system distributor `Apple', version 10.3.1038
> > configured using `configure '--with-ns' 'CFLAGS=-O0 -g''
> > Major mode: ObjC/l
--
Alan Mackenzie (Nuremberg, Germany).
next prev parent reply other threads:[~2016-02-20 22:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-11 3:01 bug#5560: 23.1.92; parens matching in c-mode broken David Reitter
2016-02-17 3:56 ` Andrew Hyatt
2016-02-20 22:57 ` Alan Mackenzie [this message]
2016-02-21 12:35 ` Alan Mackenzie
2016-02-21 21:40 ` David Reitter
2016-02-21 23:21 ` John Wiegley
2016-02-22 10:51 ` Alan Mackenzie
2016-02-22 10:35 ` Alan Mackenzie
2016-02-22 12:09 ` David Reitter
2016-02-25 9:54 ` Alan Mackenzie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160220225723.GA10801@acm.fritz.box \
--to=acm@muc.de \
--cc=5560@debbugs.gnu.org \
--cc=ahyatt@gmail.com \
--cc=david.reitter@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.