GNU bug report logs - #22884
25.0.92; C/l mode editing takes waaaayy too long

Previous Next

Full log

View this message in rfc822 format

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: eggert <at> cs.ucla.edu, 22884 <at> debbugs.gnu.org
Subject: bug#22884: 25.0.92; C/l mode editing takes waaaayy too long
Date: Fri, 4 Mar 2016 09:37:07 +0000

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 <at> cs.ucla.edu, 22884 <at> debbugs.gnu.org
> > From: Alan Mackenzie <acm <at> muc.de>

> > 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).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.