From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#18826: 24.3.94; c++-mode bad indentation after programmatic insert with locally changed syntax table Date: Sun, 26 Oct 2014 22:09:25 +0700 Message-ID: <544D0EA5.50703@yandex.ru> References: <20141025232449.90894.qmail@mail.muc.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1414336242 30662 80.91.229.3 (26 Oct 2014 15:10:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 26 Oct 2014 15:10:42 +0000 (UTC) Cc: 18826-done@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Oct 26 16:10:35 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 1XiPSj-0002mQ-Mw for geb-bug-gnu-emacs@m.gmane.org; Sun, 26 Oct 2014 16:10:33 +0100 Original-Received: from localhost ([::1]:56941 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XiPSi-00014t-GH for geb-bug-gnu-emacs@m.gmane.org; Sun, 26 Oct 2014 11:10:32 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38792) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XiPSU-00012C-Si for bug-gnu-emacs@gnu.org; Sun, 26 Oct 2014 11:10:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XiPSN-0003Uv-94 for bug-gnu-emacs@gnu.org; Sun, 26 Oct 2014 11:10:18 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:43990) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XiPSE-0003HP-V1; Sun, 26 Oct 2014 11:10:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XiPSE-0004ki-Jj; Sun, 26 Oct 2014 11:10:02 -0400 Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-To: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Sun, 26 Oct 2014 15:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: cc-closed 18826 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: Mail-Followup-To: 18826@debbugs.gnu.org, dgutov@yandex.ru, dgutov@yandex.ru Original-Received: via spool by 18826-done@debbugs.gnu.org id=D18826.141433617718228 (code D ref 18826); Sun, 26 Oct 2014 15:10:02 +0000 Original-Received: (at 18826-done) by debbugs.gnu.org; 26 Oct 2014 15:09:37 +0000 Original-Received: from localhost ([127.0.0.1]:36086 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XiPRo-0004jv-QL for submit@debbugs.gnu.org; Sun, 26 Oct 2014 11:09:37 -0400 Original-Received: from mail-pd0-f174.google.com ([209.85.192.174]:60364) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XiPRn-0004jj-2b for 18826-done@debbugs.gnu.org; Sun, 26 Oct 2014 11:09:35 -0400 Original-Received: by mail-pd0-f174.google.com with SMTP id p10so4109204pdj.19 for <18826-done@debbugs.gnu.org>; Sun, 26 Oct 2014 08:09:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=iQl/t1jiND/PMsClGQj+HNXv7LfdrNvOJsj5ti2rPWE=; b=vSASXYSTkuqE//mQh2ny7T3aD6nRBfg6/FE0JznmLAHAiJDXSQHiSrzMSqbxuC0Zdr /bEDRTqJC2hsm/7h/mHViDVMsRZYKh8cN5qLPU6dWAOotNmxPpzDbdxaRI9a2CBUbZTe dv31crgbkF9xzBu/iqaGyAaQ9XVq4hFDa83M1T7lNJE+Dr7zFvEqnyjNn8DSyT61w/d4 Igq84U/EQwv0vfOILk9cQgm6PcfUAoxZkcObdZVjCxZWZKE4New17Pp3IBFFVmTx7F4F QIb/A1gLU1bbx4vKbCMtZ5XMBrbDfxs5Tyu6PohhQdO6Xdi1IeR6cCM+DdhYGqIPRztE /grg== X-Received: by 10.70.15.228 with SMTP id a4mr18119100pdd.77.1414336169168; Sun, 26 Oct 2014 08:09:29 -0700 (PDT) Original-Received: from [192.168.2.52] ([113.160.248.69]) by mx.google.com with ESMTPSA id c10sm8556783pdj.77.2014.10.26.08.09.27 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Oct 2014 08:09:28 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 In-Reply-To: <20141025232449.90894.qmail@mail.muc.de> 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:95103 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. > 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. 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. > 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. 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.