Add a function that optimises the width of the GIF based on the sequence given

[chrisjwelly]

Currently, there is some manual work in setting the width of the GIF inside the splitbuf_draw method. Ideally, we don't want the user to be worried about the exact width of their GIF (or rather, how many characters are they supplying to the sequence being animated).

There are two possible solutions I can think of:

1. The width of the GIF depends on the capacity of the Split Buffer
2. The width of the GIF depends on the longest text the Split Buffer will ever contain

The two approaches seem similar, but there are subtle differences.

For 1: this is actually the approach used in the original gap buffer animator. However, it doesn't work the same way here, because we have broken the buffer into two arrays. With Split Buffer, it is more prone to resizing, and thus there will be an uneven GIF width. Even if we specified a large-enough Split Buffer, this will cause a high capacity, causing a lot of unused horizontal space in the GIF

For 2: This is the solution I currently prefer. For this particular solution, what can be done is once the series of commands are given, do not animate the frames yet. Use this series of commands to "simulate" what happens to the split buffer, and maintain the maximum size (number of characters it holds) in the buffer.

Then, we can set a fixed width for the GIF based on the maximum size in the buffer ever. Maybe plus some more characters as well (we can some parameter for additional character space). Only then will we run the series of command to make the animations (i.e. call FRAME() macro).

I have tried coding this out. For reference it can be found in this commit 43b4c6f of the optimise-width branch.

However, I am facing an error similar to this:

free(): invalid next size (normal)
Aborted (core dumped)

I have narrowed down the problem to this commit 417a22d , which is in the width-as-param branch. Basically, I can't seem to use the parameters of splitbuf_draw to draw the rectangles. However, a hardcoded value is fine.

I ran the following command:

valgrind --leak-check=full -v ./splitbuf-anim

and received this error message (truncated):

==3695== Invalid write of size 1
==3695==    at 0x10A14C: image_set (splitbuf-anim.c:43)
==3695==    by 0x10A14C: draw_char_postGap (splitbuf-anim.c:164)
==3695==    by 0x10A14C: splitbuf_draw (splitbuf-anim.c:185)
==3695==    by 0x10A9CA: animate (splitbuf-anim.c:254)
==3695==    by 0x10920E: main (splitbuf-anim.c:340)
==3695==  Address 0x4acc078 is 0 bytes after a block of size 7,304 alloc'd
==3695==    at 0x483CD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==3695==    by 0x10996D: image_create (splitbuf-anim.c:20)
==3695==    by 0x10996D: splitbuf_draw (splitbuf-anim.c:174)
==3695==    by 0x10A9CA: animate (splitbuf-anim.c:254)
==3695==    by 0x10920E: main (splitbuf-anim.c:340)
==3695== 
==3695== Invalid write of size 1
==3695==    at 0x10A157: image_set (splitbuf-anim.c:45)
==3695==    by 0x10A157: draw_char_postGap (splitbuf-anim.c:164)
==3695==    by 0x10A157: splitbuf_draw (splitbuf-anim.c:185)
==3695==    by 0x10A9CA: animate (splitbuf-anim.c:254)
==3695==    by 0x10920E: main (splitbuf-anim.c:340)
==3695==  Address 0x4acc07a is 2 bytes after a block of size 7,304 alloc'd
==3695==    at 0x483CD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==3695==    by 0x10996D: image_create (splitbuf-anim.c:20)
==3695==    by 0x10996D: splitbuf_draw (splitbuf-anim.c:174)
==3695==    by 0x10A9CA: animate (splitbuf-anim.c:254)
==3695==    by 0x10920E: main (splitbuf-anim.c:340)

...