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: Mon, 27 Oct 2014 08:06:46 +0700 Message-ID: <544D9AA6.5@yandex.ru> References: <20141026173849.82988.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 1414372123 20452 80.91.229.3 (27 Oct 2014 01:08:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 27 Oct 2014 01:08:43 +0000 (UTC) Cc: 18826@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Oct 27 02:08: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 1XiYnT-0002ah-Gn for geb-bug-gnu-emacs@m.gmane.org; Mon, 27 Oct 2014 02:08:35 +0100 Original-Received: from localhost ([::1]:58806 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XiYnT-0006ho-1U for geb-bug-gnu-emacs@m.gmane.org; Sun, 26 Oct 2014 21:08:35 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53160) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XiYnH-0006a7-Vc for bug-gnu-emacs@gnu.org; Sun, 26 Oct 2014 21:08:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XiYn5-00023T-9B for bug-gnu-emacs@gnu.org; Sun, 26 Oct 2014 21:08:23 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:44180) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XiYmx-00022q-8u; Sun, 26 Oct 2014 21:08:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XiYmw-0002oG-K0; Sun, 26 Oct 2014 21:08:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Mon, 27 Oct 2014 01:08: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.141437202410715 (code B ref 18826); Mon, 27 Oct 2014 01:08:02 +0000 Original-Received: (at 18826) by debbugs.gnu.org; 27 Oct 2014 01:07:04 +0000 Original-Received: from localhost ([127.0.0.1]:36278 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XiYm0-0002mk-5C for submit@debbugs.gnu.org; Sun, 26 Oct 2014 21:07:04 -0400 Original-Received: from mail-pd0-f180.google.com ([209.85.192.180]:61713) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XiYlw-0002mC-OU for 18826@debbugs.gnu.org; Sun, 26 Oct 2014 21:07:01 -0400 Original-Received: by mail-pd0-f180.google.com with SMTP id ft15so2622997pdb.25 for <18826@debbugs.gnu.org>; Sun, 26 Oct 2014 18:06:54 -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=dkmdxbcX5yfK0QpsC1n2V4Bty50SMRqlM0NXuE3Qc14=; b=TKHL0tRZDpr0GltQC28ZeTwoW8zUNognPeKyhyh9T4sBM8gmUYiJaSZFq9I1Cj030d WWU43q4VhNlsyCBkwtFioog5PtnFs9o1H0lA/RQpg2W07j3zK8R26eYppZDkdpFgHzwZ f4PI7vUfMH6VptdZKiRiuHzGJ1Ml/Rnm5qsZBbBd+3wd7mrW59sDxI0gI72TcwH6IWV6 VvgEK83/60zOhhAwJj1WdNLF9Ubep74qfUyYU+znAnGeDDwtRa4YeTiMMWIbeQ4x+NTU Al81BAqgr7N0UcZrnQHsc5hVhLg/sCMM9t28wbbF0hcz/3T4XmJof3Kzqie0SHPUOqV3 hfuQ== X-Received: by 10.68.135.97 with SMTP id pr1mr20303144pbb.121.1414372013963; Sun, 26 Oct 2014 18:06:53 -0700 (PDT) Original-Received: from [192.168.2.52] ([113.160.248.69]) by mx.google.com with ESMTPSA id dj1sm9296577pdb.10.2014.10.26.18.06.50 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Oct 2014 18:06:53 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 In-Reply-To: <20141026173849.82988.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:95134 On 10/27/2014 12:38 AM, Alan Mackenzie wrote: > They're not syntax-table text properties, so the setting of them doesn't > belong in syntax-propertize. Well, they are used to set syntax information, so syntax-propertize is a much better place for them, conceptually, than font-lock. > 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. If it's a actually a problem, maybe you need to be able to use a custom invalidation strategy. Aside from the strategy itself, this shouldn't be too hard to implement. >> 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! Thanks, but there are no "less-than" in a function signature. >>> 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. Not sure why, but ok. >> 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'. Is that much different from what I described above? I do (with-syntax-table (make-syntax-table (syntax-table) ...)