> So, Bram, what do you think of this patch? Will it see the light of day?
It's in my todo list to have a look at it. The numbers you show look
promising.
This goes to the core of storing the edited text and hash mechanisms may
have ways to fail. How are we going to torture-test this?
--
If you put 7 of the most talented OSS developers in a room for a week
and asked them to fix a bug in a spreadsheet program, in 1 week
you'd have 2 new mail readers and a text-based web browser.
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
It looks good, but this is quite a big change to an important part of
the code. We need a few good tests for this.
The most tricky function is mf_hash_grow(). It's only invoked for big
files. Well, a buffer with lots of lines, the lines can be short. With
a script adding lines with the line number, and then checking that the
right number can be read back, should cover the basic case.
The requirement to have the "next" and "previous" pointers in a specific
position isn't very clean. Perhaps it's not too inconvenient to
use mf_hashitem_T in those places and access its members through a few
macros (with type casts).
An alternative is to do everything with bhdr_T and use a type cast for
NR_TRANS only. That simplifies things, although it still has the
requirement that the two structures start with those three specific
items.
For code layout: please put { in a separate line in a few places.
Keep the lines shorter than 80 characters.
--
Be thankful to be in a traffic jam, because it means you own a car.