GNU bug report logs - #16526
24.3.50; scroll-conservatively & c-mode regression

Previous Next

Full log

Message #189 received at 16526 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 16526 <at> debbugs.gnu.org
Subject: Re: bug#16526: 24.3.50; scroll-conservatively & c-mode regression
Date: Sat, 28 Jun 2014 16:30:59 +0000

Hi, Eli.

On Sat, Jun 28, 2014 at 06:12:53PM +0300, Eli Zaretskii wrote:
> > Date: Sat, 28 Jun 2014 14:55:09 +0000
> > From: Alan Mackenzie <acm <at> muc.de>
> > Cc: 16526-done <at> debbugs.gnu.org

> > This particular scan-lists which took 0.7s had to traverse 65 comments,
> > of which 29 had an odd number of apostrophes.  Scanning xdisp.c from BOB
> > to syms_of_xdisp on my machine takes 0.024s.  28 * 0.024s = 0.67s.  So if
> > there were simple cacheing in syntax.c, such that the scan from BOB was
> > done at most once for each scan-lists, the sluggishness would largely
> > vanish in this case.

> Sorry for asking the obvious: why cannot the code know that an
> apostrophe inside a comment is just a simple character of no special
> significance?  Why does it need to treat apostrophes _inside_comments_
> specially?

I think it's because whilst scanning backwards, it's not known that the
comment ender actually ends a comment.  For example:

    /*    */   "       /*     "   */
                              ^
			      |

.  Here we actually have a comment followed by a string followed by an
unmated comment closer.  If, at the marked position, we were to assume
that the " was "nothing special", we'd mis-parse the above as a comment
containing a quote mark, then get horribly confused trying to find the
mating double quote mark for the first ".  Or something like that.

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