[PING^2][PATCH] [gdb/build] Remove dependency on _rl_term_autowrap

[Tom de Vries <tdevries@suse.de>]

On 5/16/23 10:53, Tom de Vries via Gdb-patches wrote:
> On 5/1/23 09:45, Tom de Vries wrote:
>> [ was: Re: [pushed] [gdb/tui] Fix TUI resizing for TERM=ansi ]
>>
>> On 4/30/23 21:15, Tom Tromey wrote:
>>>>>>>> "Tom" == Tom de Vries via Gdb-patches 
>>>>>>>> <gdb-patches@sourceware.org> writes:
>>>
>>> Tom> As it happens, when TERM is set to ansi, readline decides that 
>>> the terminal
>>> Tom> cannot auto-wrap lines, and reserves one column to deal with 
>>> that, and as a
>>> Tom> result reports back one less than the actual screen width:
>>> ...
>>> Tom> This is currently not causing trouble in testing because we have 
>>> a workaround
>>> Tom> in place in proc Term::resize.  If we disable the workaround:
>>>
>>> Thank you for tracking this down.
>>> I never even considered this might be a readline issue.
>>>
>>> Tom> +      readline_hidden_cols = _rl_term_autowrap ? 0 : 1;
>>>
>>> I hate to have a new dependency on a readline internal variable.
>>
>> Agreed, it's ugly.
>>
>>> Don't some distros mark these as hidden in libreadline.so?
>>> I feel like there was another bug along these lines.
>>>
>>
>> That's probably PR10723 - "Dependency on readline internal variable" ( 
>> https://sourceware.org/bugzilla/show_bug.cgi?id=10723 ).
>>
>>> However, I don't see another way to do it.
>>
>> I had an earlier version of the patch that used the COLUMNS env 
>> variable instead.  It felt a bit hacky, so I went for 
>> _rl_term_autowrap, but patch attached below goes back to the COLUMNS 
>> approach.  WDYT?
>>
> 

Ping^2.

Thanks,
- Tom

> 
> If this is not acceptable, I'll bring up making the variable public on 
> the readline mailing list.
> 
> Thanks,
> - Tom
> 
>>> Maybe some official API could be added by the upstream readline.
>>> Would you want to bring it up there?
>>>
>>
>> If we commit the patch below, then this is solved for 
>> _rl_term_autowrap, but not for the other instances.
>>
>> I expect bringing it up will will need to be done per instance, with a 
>> detailed explanation of why we need it, so that sounds like project I 
>> don't have time for atm.
>>
>>> Anyway it seems ok to me.
>>
>> Thanks for the review.
>>
>> - Tom
>