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#22884: 25.0.92; C/l mode editing takes waaaayy too long Date: Tue, 8 Mar 2016 14:02:05 +0000 Message-ID: <20160308140205.GA6269@acm.fritz.box> References: <56D72C35.4090708@cs.ucla.edu> <20160303124910.GA2852@acm.fritz.box> <56D87A6E.8090202@cs.ucla.edu> <83povbz3mp.fsf@gnu.org> <56D8CC45.2090102@cs.ucla.edu> <20160304144759.GB2117@acm.fritz.box> <56D9F0C6.4090800@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1457445641 24032 80.91.229.3 (8 Mar 2016 14:00:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 8 Mar 2016 14:00:41 +0000 (UTC) Cc: 22884@debbugs.gnu.org To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Mar 08 15:00:30 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 1adIBT-00071z-BK for geb-bug-gnu-emacs@m.gmane.org; Tue, 08 Mar 2016 15:00:23 +0100 Original-Received: from localhost ([::1]:34783 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adIBS-00034n-Vz for geb-bug-gnu-emacs@m.gmane.org; Tue, 08 Mar 2016 09:00:22 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57682) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adIBL-00033K-LF for bug-gnu-emacs@gnu.org; Tue, 08 Mar 2016 09:00:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1adIBF-00069h-F8 for bug-gnu-emacs@gnu.org; Tue, 08 Mar 2016 09:00:15 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:41615) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adIB9-00064s-8q; Tue, 08 Mar 2016 09:00:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1adIB8-0005jU-Tu; Tue, 08 Mar 2016 09:00: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: Tue, 08 Mar 2016 14:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22884 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: Original-Received: via spool by 22884-submit@debbugs.gnu.org id=B22884.145744557421974 (code B ref 22884); Tue, 08 Mar 2016 14:00:02 +0000 Original-Received: (at 22884) by debbugs.gnu.org; 8 Mar 2016 13:59:34 +0000 Original-Received: from localhost ([127.0.0.1]:38742 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1adIAg-0005iM-5w for submit@debbugs.gnu.org; Tue, 08 Mar 2016 08:59:34 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:61572) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1adIAe-0005iD-5g for 22884@debbugs.gnu.org; Tue, 08 Mar 2016 08:59:32 -0500 Original-Received: (qmail 83828 invoked by uid 3782); 8 Mar 2016 13:59:30 -0000 Original-Received: from acm.muc.de (p548A5689.dip0.t-ipconnect.de [84.138.86.137]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 08 Mar 2016 14:59:29 +0100 Original-Received: (qmail 6387 invoked by uid 1000); 8 Mar 2016 14:02:05 -0000 Content-Disposition: inline In-Reply-To: <56D9F0C6.4090800@cs.ucla.edu> 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:114572 Archived-At: Hello, Paul. On Fri, Mar 04, 2016 at 12:32:06PM -0800, Paul Eggert wrote: > Alan Mackenzie wrote: > > I have had an idea for fixing Emacs so that we don't have this problem > > with parens in column 0. That is only to scan comments in the forward > > direction, and to mark them with text properties. `back_comment' will > > then be little more than checking these text properties are up to date, > > and then doing a backward text property search. > Would this mean we no longer need to put \( into Elisp doc strings too? It has > always been annoying that we have to do that. > If it's practical to fold your idea into the emacs-25 branch it sounds like > it'll solve the problem. If it's safer to put such a change into the master > branch, I can install the patch I already wrote into the emacs-25 branch, as a > stopgap. What do you think? OK, I've hacked this out and committed it to the new branch "comment-cache", branched off of master. To use it, (setq comment-cacheing-flag t), and enjoy! The old `back_comment' is still in syntax.c, renamed to `old_back_comment', and it is used when that flag is left at nil. There should no longer be any restrictions about open parentheses in column 0, neither in comments nor in strings. open-paren-in-column-0-is-defun-start should now be a relic (although it still appears in some lisp files). At the moment, the code only uses the cached information (on the `comment-depth' text property) for moving backwards over comments. It could be enhanced also to use this information for moving back over strings, or moving forward over comments and strings, but this is more of an optimisation than new functionality, and I'm not convinced the saving would be all that much. (At the end of any such move, the variables `from' and `from_byte' are out of synch, and a CHAR_TO_BYTE invocation is necessary. I don't know how slow or fast this is.) As I've said already, the new scheme comes with one or two minor restrictions: any Lisp code which chnages the syntax table in a way which affects how literals are handled needs also to call `trim-comment-cache' to invalidate the cache. The same applies to anybody tweaking the `syntax-table' property of a symbol which is the value of a `category' text property. CC Mode does the latter extensively, and I'll need to prepare a version which doesn't do this. At the moment, the code hasn't yet been tested with nestable comments, or `category' text properties. Can you recommend me a major mode with nestable comments? I haven't really tested it for narrowing, either, or anything like indirect buffers. I'm not convinced by the names I've chosen for all the new functions and variables, and I think I ought to rename "comment-cache" to "literal-cache", and likewise for all the rest. Some amendment of the Elisp manual will be needed to document the new minor restrictions. I look forward to your comments! -- Alan Mackenzie (Nuremberg, Germany).