On 8 April 2012 06:09, Jason Merrill <ja...@redhat.com> wrote:
> On 04/07/2012 06:29 PM, Manuel López-Ibáńez wrote:
>> I'll be happy to change it to whatever is more understandable. I think
>> in CSS is called "padding".
> That wouldn't be any clearer; my confusion was that I thought you were
> padding the right side of the source line, but you aren't; you are only
> making sure that the caret isn't too close to the edge of the terminal. No
> need to change anything here.
>> +getenv_columns (void)
> I had been thinking to check COLUMNS once at the beginning of compilation; I
> don't think the value can change while the compiler is running since we
> don't respond to SIGWINCH. And let's use this value in
> c_common_initialize_diagnostics, too.
That code is useless. It is overridden by cxx_initialize_diagnostics
(line 2429). It is not strange that nobody noticed this because the
pretty-printer code is hard to understand and impossible to debug. I'd
rather not touch it if I can avoid it.
I am not even sure if that is the correct way to set the line-cut-off
in PP. The option fmessage-length uses pp_set_line_maximum_length. Who
knows what is the correct way?
Also, using COLUMNS to initialize pp's line-cut-off will change the
current default (which is unlimited despite what invoke.texi says).
I can add "locus_max_width" to diagnostic_context, and use
getenv_columns to initialize it once. Would that be ok?