Closed brycereitano closed 10 years ago
I' should've put a copyright on the number 2048 before that hideous game came out... Anyway, chunked input is a no-no due to the internal structure of bar, should I just raise the limit to 4096 ?
You can't fight the addictive nature of that game.
As a temporary solution that would be viable. The real problem is that its becoming very verbose if you change the colors often. Same thing happens when multiple screens are available and you want the same output on all them. "%{S0} The output. %{S1} The output. %{S2} The output." Of course, that could be the ignorance of myself and not doing something correctly.
I've been looking at dynamically allocating more character space if needed. If not that, another option would be adding a parameter flag to how many characters per line should be allocated. I will make a pull request if I find a stable method of doing either.
The solution is to use the FIONREAD ioctl on stdin and allocate a buffer accordingly. But you'd either need to malloc/realloc it every time otherwise you're just wasting potentially useful ram
Why not set the buffer on startup, for example ./bar -charbuffer 2048
or somethings like that ?
It'd be ugly, the end user should not care about the gory details of memory allocation
The 2048 character limit is really small when you start trying to have lots of colors and multiple monitors. I also think the 2048 character limit should be handled a lot nicer than it already is. If you go over the limit, the bar text starts to flash. I have not fixed it locally, but I'll look into it.
Edit, just changing the allocation of characters is working for now.