From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.cc-mode.general,gmane.emacs.devel Subject: A possible way for CC Mode to resolve its sluggishness Date: Fri, 26 Apr 2019 19:30:56 +0000 Message-ID: <20190426193056.GC4720@ACM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="250797"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) To: emacs-devel@gnu.org, bug-cc-mode@gnu.org Original-X-From: cc-mode-help-bounces@lists.sourceforge.net Fri Apr 26 21:31:27 2019 Return-path: Envelope-to: sf-cc-mode-help@m.gmane.org Original-Received: from lists.sourceforge.net ([216.105.38.7]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hK6ZD-00138h-OX for sf-cc-mode-help@m.gmane.org; Fri, 26 Apr 2019 21:31:27 +0200 Original-Received: from [127.0.0.1] (helo=sfs-ml-1.v29.lw.sourceforge.com) by sfs-ml-1.v29.lw.sourceforge.com with esmtp (Exim 4.90_1) (envelope-from ) id 1hK6Z3-0007x1-6P; Fri, 26 Apr 2019 19:31:17 +0000 Original-Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-1.v29.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1hK6Z1-0007wm-Q0 for cc-mode-help@lists.sourceforge.net; Fri, 26 Apr 2019 19:31:15 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=From:Content-Type:MIME-Version:Message-ID:Subject: To:Date:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=NqWaUTcVhlf00ns5v0iy11Uah4OlkhiQ1x1UgXi5Ilk=; b=ZzzWaIz2gSULyooUMb6V6w0Few wzHPbpt+xYAA8lDmwdQ4VpD8L6TGHfMhk9huGviPJnz74t22egBbDvnbdvywU/kUbu8B33qzkKnTI 6ZexwAmlcCvqSwsJxOMcuWgJJ4+aSQC/eObI5efy/RbHF8NqgDsm//diSVyMSIbrWaVE=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=From:Content-Type:MIME-Version:Message-ID:Subject:To:Date:Sender:Reply-To :Cc:Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive; bh=NqWaUTcVhlf00ns5v0iy11Uah4OlkhiQ1x1UgXi5Ilk=; b=I 265wNNLMoQxvkfLoyS0X+QCsXDuzhiKJb5PsXCHlbmYkLzrrbVm5pGIhKHHuzel/O5T0lOW9fzRIk rcClrT9X6whtdAV06YIHBATTXChXiRsAbwzUtS0B2dYvnPRBddgMJER2t/A5lGSywUM0cJGJ/eHAQ LOKn1L1b5M8usi9I=; Original-Received: from eggs.gnu.org ([209.51.188.92]) by sfi-mx-4.v28.lw.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.90_1) id 1hK6Z0-00EGpq-1P for cc-mode-help@lists.sourceforge.net; Fri, 26 Apr 2019 19:31:15 +0000 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:59908) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hK6Ys-0007zW-7Y for cc-mode-help@lists.sourceforge.net; Fri, 26 Apr 2019 15:31:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52593) by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hK6Ys-0006Kv-0q for bug-cc-mode@gnu.org; Fri, 26 Apr 2019 15:31:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hK6Yq-0007xb-4h for bug-cc-mode@gnu.org; Fri, 26 Apr 2019 15:31:05 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:53523 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1hK6Yo-0007rF-9U for bug-cc-mode@gnu.org; Fri, 26 Apr 2019 15:31:04 -0400 Original-Received: (qmail 1599 invoked by uid 3782); 26 Apr 2019 19:30:58 -0000 Original-Received: from acm.muc.de (p4FE15E52.dip0.t-ipconnect.de [79.225.94.82]) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 26 Apr 2019 21:30:57 +0200 Original-Received: (qmail 31093 invoked by uid 1000); 26 Apr 2019 19:30:56 -0000 Content-Disposition: inline X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Headers-End: 1hK6Z0-00EGpq-1P X-BeenThere: cc-mode-help@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Bug reports, feature requests, and general talk about CC Mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: cc-mode-help-bounces@lists.sourceforge.net Xref: news.gmane.org gmane.emacs.cc-mode.general:7610 gmane.emacs.devel:235965 Archived-At: Hello Emacs, CC Mode. In the last few years there's been a continual stream of posts complaining (always good naturedly) about the sluggishness of CC Mode during extended buffer change operations, and sometimes even with single operations (such as typing into a C++ raw string). Recently, Zhang Haijun, noted that iedit-mode (a mode that performs simultaneous edits on, say, all occurrences of a variable name throughout a buffer) didn't work well in C++ Mode, because of the time taken by its after-change-functions. The problem is that CC Mode's before/after-change-functions are very general, and scan the buffer looking for situations which only arise sporadically. Things like an open string getting closed, or a > being inserted which needs to be checked for a template delimiter. However, these expensive checks are performed for _every_ buffer change. Even doing something like inserting a letter or a digit causes the full range of tests to be performed. This is not good. To improve this, I propose that at a buffer change, simple fast plausibility checks be performed before the change-functions get run, and only where something complicated is afoot should (selected) change-functions be run. For example, inserting a letter or digit will only rarely be complicated, inserting a brace or semicolon will usually be so. Now to the detailed proposal: (i) A CC Mode buffer will be partitioned into @dfn{syntactic cells}. These will be things like a section of code, a comment, a string, a raw string, a CPP construct .... Possibly even comment delimiters would have their own cells. (ii) Syntactic cells will be implemented by a text property, c-syntax, whose value will indicate the type of the cell, and possibly an identifier for it. Neighbouring cells will always have distinct c-syntax values. (iii) On a buffer change which removes characters, we check for things like: o - (beg end) straddling or touching cell borders; o - "structural" characters in (beg end) (say a brace or semicolon); o - "boundary" characters in (beg end) (say a comment or string delimiter); o - things happening with backslashes, etc. If any of these things is true, we run the before-change-functions (or a subset of them). This will only happen every now and then. When it does, we will likely adjust the syntactic cells. (iv) When a buffer change inserts characters, we check basically the same things as in (iii) and if needed, run (a subset of) the after-change-functions. This also will only happen now and then, and will like necessitate adjustment of the syntactic cells. It will probably be possible to eliminate one or more existing CC Mode structural caches - the speed of text property search (compared with parse-partial-sexp from a cached "safe" position) will make this possible. Thoughts? -- Alan Mackenzie (Nuremberg, Germany).