[feature] make INPUT_BUF_LIMIT configurable

[amigthea]

I think that this hardcoded value should be configurable as an environment variable, it would be very handy to let users displays bigger images.

Could this be implemented?

[nicm]

Yes you could make it a server option easily enough (I'd suggest calling it input-buffer-size).

[amigthea]

Unfortunately I do not have the skills required for a commit like that, but thank you for the suggestion, maybe someone will pick that up! =)

[kenlau46]

Hi @nicm and @amigthea, I think I could help in here.

Since I only use basic functions in tmux (despite have been using it since tmux 1.8) and new to the code, so before start coding, I would like to ask if my approach is correct.

So the new option is to control how many characters the client read or process before discarding, e.g. if INPUT_BUF_LIMIT is 4 and user input is 12345, then 5 should be discard and not displayed?

The place/code to be changed are:

1. Add the option input-buffer-size in options-table.c . It is .type OPTIONS_TABLE_NUMBER and .scope is OPTIONS_TABLE_PANE. The default value is to align with INPUT_BUF_LIMIT in input.c
2. in input.c, each time input_input() we call options_get_number() instead of using INPUT_BUF_LIMIT
3. Edit tmux.1 to reflect new sever setting in man page

Hope I didn't miss any thing.

[nicm]

Nearly, I would just make this a server option not a pane option, I don't see much use to changing it for each pane.

Don't call options_get_number for every call to input_input because it will be too slow, you will need to cache the value. So add a global variable to input.c and a function like input_set_buffer_size which you can call from options_push_changes.

[kenlau46]

@nicm the patch tmux_discussions_4225.patch is created according your advice.

I am sorry that I don't know how to test this feature, but I checked if the option is applied correctly by checking the tmux server log, as well as checking $ tmux show -s. The default minimum value is 32, which is to align with INPUT_BUF_START in input.c.

While working on the patch, I noticed that the maximum and the minimum inside struct options_table_entry is u_int, but the default_num is long long. It looks like a type mismatch, is it intended? I saw the function (strtonum()) that use the maximum and the minimum are accepted as long long though.

[nicm]

Looks good, applied to OpenBSD now with some trivial changes (and I increased the minimum size), will be in GitHub later. Thanks!

I don't think it matters than minimum/maximum are u_int, there isn't any real case for any of the values being larger.