bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#16526: 24.3.50; scroll-conservatively & c-mode regression


From: Alan Mackenzie
Subject: bug#16526: 24.3.50; scroll-conservatively & c-mode regression
Date: Sat, 28 Jun 2014 16:30:59 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

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@muc.de>
> > Cc: 16526-done@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).





reply via email to

[Prev in Thread] Current Thread [Next in Thread]