[RFC] diagnostics.c: For terminals, restrict messages to terminal width?

On 10 December 2014 at 12:10, Dodji Seketeli <dodji@redhat.com> wrote:
>>
>> 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.)
>
> I guess we should adjust the documentation to mention COLUMNS.
>
> Manuel, was there a particular reason to avoid mentioning the COLUMNS
> environment variable in the documentation?

Not that I remember. Perhaps the documentation should say something
like: "The line is truncated to fit into n characters only if the
option -fmessage-length=n is given, or if the output is a TTY and the
COLUMNS environment variable is set."

>> (b) Should ioctl be always used or only for Fortran?
>
> I'd go for using it in the common diagnostics framework, unless there is
> a sound motivated reason.  Manuel, do you remember why we didn't query the
> TIOCGWINSZ ioctl property to get the terminal size when that capability
> was available?

I was not aware this possibility even existed.

>> Comments?

Note that Fortran has this:

#ifdef GWINSZ_IN_SYS_IOCTL
# include <sys/ioctl.h>
#endif

Not sure if this is needed for diagnostics.c or whether it needs some
configure magick.

I also agree with FX that the function should be named something like
get_terminal_width().

In fact, I would argue that the Fortran version should be a wrapper
around this one to make the output consistent between the new Fortran
diagnostics and the old ones (*_1 variants) while the transition is in
progress, even if that means changing the current ordering for
Fortran. So far, there does not seem to be any reason to prefer one
ordering over the other, but whatever it is chosen, it would be better
to be consistent. Thus something like:

Manuel López-Ibáñez <lopezibanez@gmail.com> writes:

[...]

> On 10 December 2014 at 12:10, Dodji Seketeli <dodji@redhat.com> wrote:

[...]

>> Manuel, was there a particular reason to avoid mentioning the COLUMNS
>> environment variable in the documentation?
>
> Not that I remember. Perhaps the documentation should say something
> like: "The line is truncated to fit into n characters only if the
> option -fmessage-length=n is given, or if the output is a TTY and the
> COLUMNS environment variable is set."

Agreed.  Thank you.

>>> (b) Should ioctl be always used or only for Fortran?
>>
>> I'd go for using it in the common diagnostics framework, unless there is
>> a sound motivated reason.  Manuel, do you remember why we didn't query the
>> TIOCGWINSZ ioctl property to get the terminal size when that capability
>> was available?
>
> I was not aware this possibility even existed.

Ok :-) Let's go for this then.

[...]

> Note that Fortran has this:
>
> #ifdef GWINSZ_IN_SYS_IOCTL
> # include <sys/ioctl.h>
> #endif
>
> Not sure if this is needed for diagnostics.c or whether it needs some
> configure magick.

I would guess that it should work to use that same #ifdef
GWINSZ_IN_SYS_IOCTL ... #endif snippet in diagnostics.c because, looking
at gcc/configure.ac, I see that we use the autoconf macro
AC_HEADER_TIOCGWINSZ and the autoconf documentation for that macro
reads:

 -- Macro: AC_HEADER_TIOCGWINSZ
     If the use of `TIOCGWINSZ' requires `<sys/ioctl.h>', then define
     `GWINSZ_IN_SYS_IOCTL'.  Otherwise `TIOCGWINSZ' can be found in
     `<termios.h>'.

     Use:

          #ifdef HAVE_TERMIOS_H
          # include <termios.h>
          #endif

          #ifdef GWINSZ_IN_SYS_IOCTL
          # include <sys/ioctl.h>
          #endif

I am not sure why we were not using the termios.h case though.

> I also agree with FX that the function should be named something like
> get_terminal_width().

Agreed as well.

> In fact, I would argue that the Fortran version should be a wrapper
> around this one to make the output consistent between the new Fortran
> diagnostics and the old ones (*_1 variants) while the transition is in
> progress, even if that means changing the current ordering for
> Fortran. So far, there does not seem to be any reason to prefer one
> ordering over the other, but whatever it is chosen, it would be better
> to be consistent.

I prefer that the environment variable taking precedent is better from a
usability standpoint because it's easier for the user to force the
behaviour she wants by setting an environment variable than by messing
up with some system-wide configuration what would change the output of
querying the TIOCGWINSZ property using an ioctl.

So the patch you (Manual) are proposing looks fine to me, with the
environment variable taking precedence, *if* that is fine for Fortran,
of course.

[...]

Cheers,

> So the patch you (Manual) are proposing looks fine to me, with the
> environment variable taking precedence, *if* that is fine for Fortran,
> of course.

That seems fine to me, from the Fortran standpoint. COLUMNS is a bit of a special environment variable, which the shell (when it provides it) keeps synchronized to the terminal width anyway (as is the case for bash and zsh).

FX