[RFC] diagnostics.c: For terminals, restrict messages to terminal width?
Tobias Burnus
burnus@net-b.de
Sat Dec 6 22:15:00 GMT 2014
This patch fixes a Fortran diagnostic "regression".
With the current common diagnostic, the width shown with caret
diagnostic is determined by:
case OPT_fmessage_length_:
pp_set_line_maximum_length (dc->printer, value);
diagnostic_set_caret_max_width (dc, value);
plus
diagnostic_set_caret_max_width (diagnostic_context *context, int value)
{
/* One minus to account for the leading empty space. */
value = value ? value - 1
: (isatty (fileno (pp_buffer (context->printer)->stream))
? getenv_columns () - 1: INT_MAX);
if (value <= 0)
value = INT_MAX;
context->caret_max_width = value;
}
where getenv_columns looks at the environment variable COLUMNS.
Note that -fmessage-length= applies to the error message (wraps) _and_
the caret diagnostic (truncates) while the COLUMNS variable _only_
applies to the caret diagnostic. (BTW: The documentation currently does
not mention COLUMNS.)
On most terminals, which I tried, COLUMNS does not seem to be set. In
Fortran, error.c's get_terminal_width has a similar check, but
additionally it uses ioctl to determine the terminal width.
I think with caret diagnostics, it is useful not to exceed the terminal
width as having several "empty" lines before the "^" does not really
improve the readability. Thus, I would propose to additionally use
ioctl. Which rises two questions: (a) Should the COLUMNS environment
variable or ioctl have a higher priority? [Fortran ranks ioctl higher;
in the patch, for backward compatibilty, I rank COLUMNS higher.] (b)
Should ioctl be always used or only for Fortran?
Comments?
Tobias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diag.diff
Type: text/x-patch
Size: 1272 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20141206/7ee4804d/attachment.bin>
More information about the Fortran
mailing list