Subject: Re: bug#16526: 24.3.50; scroll-conservatively & c-mode regression. The purpose of revision 116070.

From: Alan Mackenzie <[email-masked]>
Date: Sat, 25 Jan 2014 20:27:21 +0000

Hello, Martin and Eli.

On Sat, Jan 25, 2014 at 03:58:57PM +0100, martin rudalics wrote:
>  > Probably.  I actually don't understand how come scroll-conservatively
>  > affects non-scrolling commands.  Can you elaborate on that?

> How should I know?  I suppose redisplay_window eventually winds up
> calling the fontification function and sooner or later the c-code calls
> back_comment.

Yes.

>  > You also mentioned back_comment doing something unreasonable.  Can you
>  > expand on that, too?  This part specifically I don't understand:

>  >> What happens is that apparently back_comment 530 times scans the buffer
>  >> from the beginning of the buffer to the first comment before the current
>  >> position where the list of current positions goes like this:

>  > Since the problem happens as result of beginning-of-buffer, why would
>  > back_comment need to "scan the buffer from the beginning of the buffer
>  > to the first comment before the current position"?  And what is the
>  > current position in this case?

> I earlier posted the first and last positions here:

> (780 14143 15852 18026 20032 20480 21464 21846 22845 23484 25453 26968
> ...
> 942907 943099 944334 948653 948830 948653 948830 948653 948830 948653
> 948830 780 12)

> You can try by yourself.  I gathered the positions in the following
> excerpt

> find_defun_start (ptrdiff_t pos, ptrdiff_t pos_byte)
> {
>    ptrdiff_t opoint = PT, opoint_byte = PT_BYTE;

>    if (!open_paren_in_column_0_is_defun_start)
>      {
>        find_start_value = BEGV;
>        find_start_value_byte = BEGV_BYTE;
>        find_start_buffer = current_buffer;
>        find_start_modiff = MODIFF;
>        find_start_begv = BEGV;
>        find_start_pos = pos;
>        <---------------------------- right here
>        return BEGV;
>      }

>  > Btw, if I disable font-lock ("M-x global-font-lock-mode RET") before
>  > repeating the recipe, the move to bob is instantaneous, and turning on
>  > font-lock after that doesn't seem to have any adverse effects on
>  > responsiveness.

> Sure.  The problem happens obviously via jit-lock.  But IMHO disabling
> `open-paren-in-column-0-is-defun-start' IS asking for trouble as long as
> back_comment doesn't rely on `syntax-ppss' to find a safe position.

The reason I disabled open-paren-etc. was a bug report from Michael Welsh
Duggan, where commented out code was causing the CC Mode "state cache" to
get corrupted.  The critical bit of his source looks like this (note the
commenting out at L3):

 1. #define PARTIAL_MD5_SIZE 4096
 2.
 3. /*
 4.
 5. TODO: Partial sums (for working with very large files).
 6.
 7. typedef struct _signature
 8. {
 9.   md5_state_t state;
10.   md5_byte_t  digest[16];
11. } signature_t;
12.
13. typedef struct _signatures
14. {
15.   int         num_signatures;
16.   signature_t *signatures;
17. } signatures_t;
18.
19. */
20.
21. typedef struct _file {

With pos at BOL21, (scan-lists pos -1 -1) was returning BOL17.  It was
ignoring the commenting out.  Fscan_lists calls scan_lists which calls
back_comment.  Because open-paren-etc. was t, back_comment was tripping
up on the brace at BOL14 and thus not recognising the comment at all.

The "solution" to the bug was to bind open-paren-etc. to nil around the
critical code.  This is almost certainly what is causing the slow down.

Though for some reason, I don't see this slow down myself.  This is quite
worrying.  I am using an up-to-date (as of yesterday evening) bzr Emacs
and following your (Martin's) recipe by yanking it into a buffer and
doing C-x C-e on it.

If I've understood correctly, I think the root cause of the slowness is
the lack of optimisation of find_defun_start when open-paren-etc. is nil
- it brutally returns BOB, no matter what.  Perhaps some sort of cache of
safe positions (doesn't one exist already?) could accelerate
find_defun_start to acceptable speed in this use case.

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).