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

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

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.

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