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: Stefan Monnier
Subject: bug#16526: 24.3.50; scroll-conservatively & c-mode regression
Date: Sun, 29 Jun 2014 17:39:15 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

> No, syntax-ppss wouldn't do here without considerable modification.

Why?

> scan-lists must be utterly robust.  syntax-ppss can get confused if the
> user changes the syntax-table,

Indeed, the user shouldn't change the syntax-table ;-)

> or adds systax-table text properties,

The user should do that via syntax-propertize.

> or binds before-change-functions to nil and makes a change.

User gets what she deserves.  Binding inhibit-modification-hooks while
making changes is dangerous, but binding before-change-functions to nil
is simply evil and asking for trouble.

> How about simply (tm) find-defun-start actually determining a defun
> start (when open-paren-..-defun is nil) the first time it is called for
> an invocation of scan-lists, then remembering this position for
> subsequent use?

That's indeed what syntax-ppss would do.  But if the syntax-table may
change (or added as text-properties, or if before-change-functions is
let-bound to nil while making modifications), any such mechanism is
bound to fail because in those cases it shouldn't "remember this
position for subsequent use".

> As an enhancement, which would work well for scan-lists at top level
> with a large negative COUNT, we could keep a list of top level positions
> during the initial scan, say every ~5k characters.  (Or even store the
> actual parse states every 5k characters exactly.)

You're describing syntax-ppss.


        Stefan





reply via email to

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