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

Previous Next

Full log

View this message in rfc822 format

From: Alan Mackenzie <acm <at> muc.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: martin rudalics <rudalics <at> gmx.at>, 16526-done <at> debbugs.gnu.org
Subject: bug#16526: 24.3.50; scroll-conservatively & c-mode regression
Date: Fri, 4 Jul 2014 19:29:02 +0000

Hi, Stefan.

On Wed, Jul 02, 2014 at 09:57:23PM -0400, Stefan Monnier wrote:
> > No.  The particular rogue invocation of scan-lists which caused this
> > (sub-)thread scans from BOB to near EOB 29 times.  Inside scan-lists,
> > _NO_ changes to syntax-tables, s-t text properties etc. are possible.
> > What I'm suggesting is that cacheing that first scan from BOB will be a
> > big win for many time-consuming scan-listses.

> Here's the situation: we can add some special code to handle your case.
> But adding code which will use syntax-ppss would be more beneficial for
> 99% of the major modes.

My suggestion is less radical, in that it leaves the functionality of
scan-lists unchanged.  It's speedup may be indistinguishable from the
strategy of simply using syntax-ppss.

> Adding a cache that only works within a single scan-lists instance is
> too much trouble for too little gain.

Modulo a binding to nil (or two), it could be the same code as that
which simply uses the existing syntax-ppss cache.  Without trying it, we
don't know how big or little the gain is.

> Adding a cache that is flushed less often means either it will suffer
> from the same limitations as syntax-ppss (so we may as well use
> syntax-ppss), or it needs to additionally hook into the text-property
> and set-syntax-table code to be flushed in those extra corner cases,
> and there again these extra checks will be only useful for those rare
> modes like CC-mode and will be at best harmless and in some cases
> detrimental to performance compared to simply using syntax-ppss.

Yes, to all of that, except I doubt the performance penalty in the last
bit would be noticeable (it'd be in C code, surely?).

> IOW, using syntax-ppss for find_defun_start is The Right Thing to do.

It is the route of least effort, perhaps, which is important.  It will
give suboptimal results for modes where syntax-ppss's basic assumptions
don't hold.  But this is also true of the exising scan-lists, so isn't,
perhaps, too important.  

As a matter of interest, is there an existing mechanism for calling lisp
from random bits of the C code?

> And CC-mode should then be fixed to take advantage of it.

It being syntax-ppss.  What CC Mode frequently needs to know is whether
a given position is in a comment, string, preprocessor construct, or
other code.  parse-partial-sexp and syntax-ppss don't give enough
information for this, hence aren't used for this directly.

A long term solution may be to enhance the syntax bits of Emacs to
recognise "syntactic islands" (e.g. C preprocessor construct, shell
script "here documents" or literate programming chunks) somehow.

>         Stefan

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