GNU bug report logs -
#56393
Actually fix the long lines display bug
Previous Next
Full log
View this message in rfc822 format
>> And it's inconvenient that you have to keep a copy of its previous
>> value around, using MODIFF != UNCHANGED_MODIFIED as I did earlier is
>> much easier.
>
> We could indeed keep using MODIFF != UNCHANGED_MODIFIED (and I'm not
> really sure why you decided it was not good enough: can you describe the
> problems using it?).
>
The problem is that the loop under that condition is called whenever
redisplay_window is called. For a file like xdisp.c or dictionary.json,
that loop takes about 1 ms (on my laptop). For a file with 150K lines, it
takes about 13 ms. As I said earlier, I would prefer to avoid calling
that loop for normal typing, namely when only one character has been added
or removed from the buffer since the last redisplay. IOW, I want to make
the heuristic more precise.
>
> Alternatively, we could add a new member of 'struct buffer_text' called,
> say, unchanged_chars_modiff, and use it instead of MODIFF !=
> UNCHANGED_MODIFIED in the same way as we use MODIFF !=
> UNCHANGED_MODIFIED.
>
> My point is that if you want the member you added, unchanged_size, to be
> as responsive to text changes as BUF_CHARS_MODIFF, you will need to add
> code to increment it in all the places where we already do that with
> BUF_CHARS_MODIFF, and that sounds like redundancy, since we don't really
> care about how many characters were added/deleted/replaced.
>
AFAIU that's not correct: like unchanged_modified, unchanged_size must be
updated only when redisplay ends, namely in
mark_window_display_accurate_1.
This bug report was last modified 3 years and 33 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.