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 <c...@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
