From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#5560: 23.1.92; parens matching in c-mode broken Date: Sat, 20 Feb 2016 22:57:23 +0000 Message-ID: <20160220225723.GA10801@acm.fritz.box> References: <4B60ED87-9CF5-464A-AE3F-C948ADB1C4D2@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1456008921 24330 80.91.229.3 (20 Feb 2016 22:55:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 20 Feb 2016 22:55:21 +0000 (UTC) Cc: David Reitter , 5560@debbugs.gnu.org To: Andrew Hyatt Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Feb 20 23:55:10 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aXGQf-0005cA-VO for geb-bug-gnu-emacs@m.gmane.org; Sat, 20 Feb 2016 23:55:10 +0100 Original-Received: from localhost ([::1]:36153 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aXGQf-0000Mh-16 for geb-bug-gnu-emacs@m.gmane.org; Sat, 20 Feb 2016 17:55:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41794) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aXGQb-0000M7-JT for bug-gnu-emacs@gnu.org; Sat, 20 Feb 2016 17:55:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aXGQY-0008IB-Dy for bug-gnu-emacs@gnu.org; Sat, 20 Feb 2016 17:55:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:38540) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aXGQY-0008I7-A1; Sat, 20 Feb 2016 17:55:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aXGQY-0004S3-2O; Sat, 20 Feb 2016 17:55:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Sat, 20 Feb 2016 22:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 5560 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: Original-Received: via spool by 5560-submit@debbugs.gnu.org id=B5560.145600890117101 (code B ref 5560); Sat, 20 Feb 2016 22:55:02 +0000 Original-Received: (at 5560) by debbugs.gnu.org; 20 Feb 2016 22:55:01 +0000 Original-Received: from localhost ([127.0.0.1]:35667 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aXGQX-0004Rl-4p for submit@debbugs.gnu.org; Sat, 20 Feb 2016 17:55:01 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:61383) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aXGQV-0004Rb-8L for 5560@debbugs.gnu.org; Sat, 20 Feb 2016 17:54:59 -0500 Original-Received: (qmail 6476 invoked by uid 3782); 20 Feb 2016 22:54:57 -0000 Original-Received: from acm.muc.de (p548A46B3.dip0.t-ipconnect.de [84.138.70.179]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 20 Feb 2016 23:54:56 +0100 Original-Received: (qmail 18716 invoked by uid 1000); 20 Feb 2016 22:57:23 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:113386 Archived-At: 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 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).