Re: [dev] [dmenu] bugs and senselessness

Hi Connor,

I use dmenu with dclip, and i need dynamic reallocation in order to
paste big selections. If you set a fixed size buffer, it will be
splitted in several items of that size and paste all those fragments
become a mess.

Also, take into account that in my dmenu fork (where i use this patch),
I don't have cursor support, obviously I wont edit a 4096+ byte buffer
in dmenu :)

Kind regards,
-- nibble

On Thu, 1 Apr 2010 19:40:05 +0000
Connor Lane Smith <cls_AT_lubutu.com> wrote:

> Hey,
>
> The last dmenu revision doesn't make any sense. It goes through a load
> of hassle and complexity dynamically reallocating memory, and then has
> no real effect, because text is a fixed 4096 byte buffer. Items longer
> than 4096 chars are just plain inaccessible.
>
> There are two options here. Either at the end of readstdin we can
> "text = malloc(max)", and then pass around "max" instead of just using
> "sizeof text" (since pointers don't work in the same way as arrays)...
> which seems ugly to me... Or we can just use a 4096 byte buf in
> readstdin, which makes a lot of sense anyway.
>
> I've been working on a patch since before the recent commits anyway,
> so I've merged in the ^A and ^E keybindings, but just increased the
> size of the readstdin buf to sizeof text. If we *really* want dynamic
> allocation and to pass around a "max" value etc, I suppose I could
> merge that in instead, but I don't see the necessity: do we honestly
> need to add such complexity in order to support lines longer than
> 4096? Those are pretty epic line lengths for what is essentially a
> menu.
>
> So the following patch fixes some bugs and oddities separate to the
> whole dynamic alloc issue, as well as just increasing buf to sizeof
> text, basically doing the same job as the previous revision.
>
> Thanks,
> cls
Received on Fri Apr 02 2010 - 00:05:02 UTC