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 12:48:29 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

Hi, Martin.

On Sun, Jun 29, 2014 at 12:06:46PM +0200, martin rudalics wrote:
>  > That's a bit philosophical.  open-..-start is advertised as a high level
>  > option, and CC Mode only binds it to nil at a low level, the "engine"
>  > level.  Binding user options to set values at a low level is quite a
>  > common practice in Elisp programming.

> It is a quite bad common practice in Elisp programming.

:-)  We're down at the philosophy level again.

>  > The actual bug here is that find_defun_start in syntax.c doesn't do any
>  > cacheing, hence is scanning from BOB far too often.  How about we see
>  > how things work once this is fixed.

> We're discussing this problem for some ten years now and I'm afraid we
> won't find a solution for the imminent release.

We've been discussing it for some while, yes, but a concrete diagnosis
of the problem first happened yesterday, as far as I'm aware.  Do you
feel like fixing it?  I think you know the C code better than I do, and
you're highly motivated.  Once fixed, Stefan might be inclined to
include the fix in 24.4.

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.

The above simple cacheing might not be adequate in theory, but I'm
guessing that in practice it will be a substantial win.

> martin

-- 
Alan Mackenzie (Nuremberg, Germany)





reply via email to

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