Am 01.06.2013 16:06, schrieb Mikael Morin:
For the redirection to "less", one can use "less -S".
Still, that does not help if the output is excessively long. Try some C
(or C++) long code (e.g. 30,000 lines long), do a minor mistake there
and run it through
topformflat 0 x < in.c > out.c
and then run
export COLUMNS=10000000000
gcc out.c
You will be delighted to have first a warning message, then 100 kbytes
of source code. Followed by 50 kbytes of spaces, followed by the ^ to
show where the error is. and then it continues.
Thus, with less you either have pages over pages with the source code -
or you have to scroll for ages to the right until you find the ^ and the
problematic source location.
In the real world, such source code typically occurs for generated code
- as no one is insane enough to write such kind of code manually. But
also generated Fortran code looks rather ugly. Actually, generated code
can have excessive line lengths: Nearly all compilers have flags to lift
the line-length restriction (some even do so by default). But some
compilers have a hard limit on the number of continuation lines.
As Fortran code usually has rather short lines, I admittedly still do
not understand the problem which the patch wants to solve.
For "tee", it depends on what comes behind. For the file case, one
doesn't know how wide the final display will be. It is easy to trim
afterwards, but the converse is not true (obviously)
Well, you still have the source code file. The point of showing the
source code is to make it easier to see the mistake - not to output the
whole file every time - with the error line somewhere hidden.
The real information is in the ERROR or WARNING message together with
the file name and line number. The excerpt from the source code comes
only on top to make it easier to see where the problem is. And here, it
helps to be able to directly spot the problem - instead scrolling around.
But as stated before, it's mostly bikeshadding: There are arguments for
both and it does not matter for most of the source code. As stated
before, I am in favour of the current version. But I also don't oppose
if the settings are changed.
* * *
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
OK, thanks.
Thanks for the review!
Tobias,
who is still looking for someone to review his FINAL patch
athttp://gcc.gnu.org/ml/fortran/2013-05/msg00134.html (and possibly
also the follow-up patch).
