> Computers have much more memory now, thus we could make the buffer
> bigger. [...] I suppose making it 8K would be OK.
I'm even doubting a bit that 64K is enough for all cases. Maybe a
configuration option for this size would be better (defaulting to 64K
but others can reduce/increase the size depending on their needs)?
> But they are also much faster, thus the need for reducing the number
> of calls is smaller.
Yeah, they are faster, but mine is slow enough that I see the partial
update on most terminals. :(
> I'm mainly worried about slow remote connections. Personally that's
> where I sometimes have problems (ssh over GPRS).
I think that's where this change would shine! Suppose that vim does a
full screen update (e.g. you press page down) and this means outputting
13K bytes to the terminal. Vim does the update quite quickly but
depending on your TCP settings and the time between the actual writes
this might happen: In the 2K buffer size case the operating system sees
a bunch of 2K buffers and this might result a bunch of partial packets
whereas 13K would ensure that the packets are always full length thus it
should need less packets to transmit the full update.
> I'm not sure what the relation is between the buffer size and
> responsiveness. While typing out_flush() should be called quite
It is called quite often already. Vim won't wait for the buffer to fill
when you append a character to a line. That's only a several character
update and because you can see that the character is immediately
outputted it means the output buffer is flushed often.
My only problem is when vim does a full screen update, that's the only
case when a 2K buffer is not enough (it is enough for any other update).