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#18826: 24.3.94; c++-mode bad indentation after programmatic insert with locally changed syntax table Date: 26 Oct 2014 17:38:49 -0000 Organization: muc.de e.V. Message-ID: <20141026173849.82988.qmail@mail.muc.de> References: <86egtwgra0.fsf@yandex.ru> NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1414345169 5443 80.91.229.3 (26 Oct 2014 17:39:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 26 Oct 2014 17:39:29 +0000 (UTC) Cc: 18826@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Oct 26 18:39:22 2014 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 1XiRmj-0000eO-71 for geb-bug-gnu-emacs@m.gmane.org; Sun, 26 Oct 2014 18:39:21 +0100 Original-Received: from localhost ([::1]:57703 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XiRmi-0004I5-OP for geb-bug-gnu-emacs@m.gmane.org; Sun, 26 Oct 2014 13:39:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58443) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XiRma-0004HM-TS for bug-gnu-emacs@gnu.org; Sun, 26 Oct 2014 13:39:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XiRmW-0007XJ-2J for bug-gnu-emacs@gnu.org; Sun, 26 Oct 2014 13:39:12 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:44078) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XiRmQ-0007WY-Ps; Sun, 26 Oct 2014 13:39:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XiRmQ-00007f-6k; Sun, 26 Oct 2014 13:39:02 -0400 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: Sun, 26 Oct 2014 17:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18826 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: Original-Received: via spool by 18826-submit@debbugs.gnu.org id=B18826.1414345134456 (code B ref 18826); Sun, 26 Oct 2014 17:39:02 +0000 Original-Received: (at 18826) by debbugs.gnu.org; 26 Oct 2014 17:38:54 +0000 Original-Received: from localhost ([127.0.0.1]:36176 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XiRmH-00007G-10 for submit@debbugs.gnu.org; Sun, 26 Oct 2014 13:38:53 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:48834 helo=mail.muc.de) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XiRmE-000075-2t for 18826@debbugs.gnu.org; Sun, 26 Oct 2014 13:38:50 -0400 Original-Received: (qmail 82989 invoked by uid 3782); 26 Oct 2014 17:38:49 -0000 In-Reply-To: X-Newsgroups: gnu.emacs.bug User-Agent: tin/2.2.0-20131224 ("Lochindaal") (UNIX) (FreeBSD/8.4-RELEASE (amd64)) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.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:95121 Hi, Dmitry. In article you wrote: > On 10/26/2014 06:24 AM, Alan Mackenzie wrote: >>> Because the syntax table change is temporary and its effect should be >>> limited to my code? >> It's no so limited. The before-change-functions and after-change-functions >> hooks will be run with that syntax table active. This is not good. > I see, thanks. Somehow, I figured that those hooks would run before or > after the current command, whereas they're triggered right near any code > that makes changes to the buffer. Question answered, closing. > On the other hand, you're doing some pretty unusual things with this. If > `c-in-sws' and `c-is-sws' were added in syntax-propertize-function > (which is called on-demand), this conflict wouldn't have manifested. They're not syntax-table text properties, so the setting of them doesn't belong in syntax-propertize. It wouldn't make sense to do these in syntax-propertize for a variety of other reasons, such as efficiency. >> OK. Can I suggest an alternative? In C++ (and Java) Modes, the template >> (generic) delimiters are marked with syntax-table text properties. >> Unfortunately, at the moment this is done as part of font-locking, so >> isn't done until you display. However, if you put "(sit-for 0)" into >> your code after inserting "< ... >", this will cause a redisplay, >> allowing subsequent code to use the text properties, and a backward-sexp >> will then work. > Sounds like it should be performed during `syntax-propertize' instead. > Even if you don't like this idea now, I suspect it'll happen eventually > anyway, if only for consistency with other major modes. Maybe it will, maybe it won't. `syntax-propertize' has the disadvantage of inefficiency; at any buffer change, all syntax-table text properties after the position of the change are effectively wiped out, even where (as is usual) this isn't necessary. Also, restoring them means doing so over a potentially large region of the buffer, rather than just locally around point. But, anyway .... > In that sense, the `sit-for' suggestion is not future-proof. So I'll try > only changing the syntax table around specific functions that don't > modify the buffer text, but just move point, since that was the actual goal. Might it be possible that you could get mixed up with less-than and greater-than (or even shift-right) operators? If so, be careful! >> In the medium future (several weeks away), I'm hoping to fix CC Mode so >> that the text properties are applied to < ... > on an after-change >> function rather than at redisplay. ...., a change to use syntax-propertize needs the above change to happen first. > Hmm. My current workaround is to use a temporary syntax table that > inherits from c++-mode-syntax-table (but has angle brackets in the > 'paren' class). Sounds like it might also create a conflict, if maybe a > more subtle one. Any reason you don't use the current syntax table as the base to add the descriptors for < and > to rather than creating a new, blank one? You could use `copy-syntax-table'. -- Alan Mackenzie (Nuremberg, Germany).