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: Sun, 29 Jun 2014 14:41:51 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

On Sun, Jun 29, 2014 at 04:18:42PM +0200, martin rudalics wrote:
>  > As I suggested yesterday, what is needed is for find_defun_start to
>  > actually determine the beginning-of-defun before POS/POS_BYTE (using
>  > scan_sexps_forward) rather than just giving up and returning BOB.
>  > This position must then be cached for future find_defun_start calls.
>  > The cacheing mechanism is already in place for non-nil open-...-start.

> I don't even understand why you can't use the 9th element returned by
> `syntax-ppss' to get the beginning of the outermost defun enclosing
> `point'.

scan-lists, a primitive, must be utterly robust.  syntax-ppss is too
fragile to be used here without a lot of hardening.

syntax-ppss's cache is rendered invalid at any operation which changes
the syntax table (e.g. `modify-syntax-entry'), or changes to a different
syntax table (e.g. `with-syntax-table'), or when a syntax-table text
property/overlay is applied to the buffer, or even when a symbol's
property list is changed when that symbol is the value of a category
text property.  CC Mode does all these things, and does all of them
apart from the first during run time, not merely at mode initialisation.
Also, the syntax-ppss cache's functioning is dependent upon
before-change-functions, which can be bound to nil by any program at any
time.

If one were to harden syntax-ppss against all these things, one would
probably end up calculating the cache from scratch every time, in
effect.

scan-lists is a primitive, and must function correctly regardless of any
trickery which might be played on it.

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).





reply via email to

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