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: Fri, 4 Mar 2016 09:37:07 +0000 Message-ID: <20160304093707.GA2117@acm.fritz.box> References: <56D72C35.4090708@cs.ucla.edu> <20160303124910.GA2852@acm.fritz.box> <83si07z451.fsf@gnu.org> <20160303231823.GD3822@acm.fritz.box> <83fuw6zlqf.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1457084125 26088 80.91.229.3 (4 Mar 2016 09:35:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 4 Mar 2016 09:35:25 +0000 (UTC) Cc: eggert@cs.ucla.edu, 22884@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Mar 04 10:35:12 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 1abm8d-0005IB-7A for geb-bug-gnu-emacs@m.gmane.org; Fri, 04 Mar 2016 10:35:11 +0100 Original-Received: from localhost ([::1]:39874 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1abm8c-0006Tl-Ls for geb-bug-gnu-emacs@m.gmane.org; Fri, 04 Mar 2016 04:35:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39839) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1abm8Z-0006SO-3l for bug-gnu-emacs@gnu.org; Fri, 04 Mar 2016 04:35:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1abm8U-00037j-E7 for bug-gnu-emacs@gnu.org; Fri, 04 Mar 2016 04:35:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:35454) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1abm8U-00037c-Bt; Fri, 04 Mar 2016 04:35:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1abm8U-0004zr-2T; Fri, 04 Mar 2016 04:35: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: Fri, 04 Mar 2016 09:35: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.145708407919176 (code B ref 22884); Fri, 04 Mar 2016 09:35:02 +0000 Original-Received: (at 22884) by debbugs.gnu.org; 4 Mar 2016 09:34:39 +0000 Original-Received: from localhost ([127.0.0.1]:60814 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1abm86-0004zE-WB for submit@debbugs.gnu.org; Fri, 04 Mar 2016 04:34:39 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:29271) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1abm85-0004z5-EA for 22884@debbugs.gnu.org; Fri, 04 Mar 2016 04:34:37 -0500 Original-Received: (qmail 73073 invoked by uid 3782); 4 Mar 2016 09:34:36 -0000 Original-Received: from acm.muc.de (p579E8D6B.dip0.t-ipconnect.de [87.158.141.107]) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 04 Mar 2016 10:34:35 +0100 Original-Received: (qmail 2176 invoked by uid 1000); 4 Mar 2016 09:37:07 -0000 Content-Disposition: inline In-Reply-To: <83fuw6zlqf.fsf@gnu.org> 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:114381 Archived-At: Hello, Eli. On Fri, Mar 04, 2016 at 10:32:56AM +0200, Eli Zaretskii wrote: > > Date: Thu, 3 Mar 2016 23:18:23 +0000 > > Cc: eggert@cs.ucla.edu, 22884@debbugs.gnu.org > > From: Alan Mackenzie > > Would it be practicable to mark comments with text properties? Say, a > > property called `comment-depth' which would be either nil (meaning > > currently unknown), 0 (definitely not in a comment), 1 (definitely in a > > comment), 2 (in a nested comment), 3, ...... ? That way we could always > > scan comments in the forwards direction (which is easy) - if we need to > > go backwards over a comment without the property, we can just go back to > > a known point and scan forward. > I don't see any immediate problems with this. But doesn't creating > these properties require to solve the same problem with the specific > cases we are discussing now? No, it doesn't. The difficulties with scanning comments only happen when scanning backwards. For example, on scanning backwards for a putative line comment, we're only guessing that there's going to be a "//" earlier in the line. And that token might easily be inside a string, so we've got to keep track of string delimiters, too. Etc. open-paren-in-column-0-is-defun-start is only tested twice in syntax.c, the "most important" time being in `back-comment', where we break off the scanning when it is non-nil and we've found an open paren at column zero. By contrast, scanning comments going forward is trivial. We see the opening comment delimiter, and scan forward for the closing one, ignoring strings, possibly nested openers (/*.../*..*/), and so on. So a (forward-comment -1) would just involve going back over the closing delimiter and searching back for the `comment-depth' property being zero. If the property was unset at that point, we go back to the last place it is set and scan comments forward till we get back to our starting place. Additionally, we'd need to zap the property between point and EOB on each buffer change. Not difficult. > > Or would this just overwhelm the text property mechanism? > No, I don't think it should. Text properties scale reasonably well. > And we already have the same with faces (since comments have a > specific face), don't we? Then we have a project! -- Alan Mackenzie (Nuremberg, Germany).