This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Emacs and GFortran


"sk" == Steve Kargl writes:

 sk> On Tue, Oct 31, 2006 at 10:59:11AM +0900, Miles Bader wrote:
 sk> > "Fran?ois-Xavier Coudert" <fxcoudert@gmail.com> writes:
 sk> > 
 sk> > > Frankly, I strongly prefer the current error formating.

 sk> I agree with FX.

"Prefer"?  Me too.  But it's not worth giving up the GNU standard
error format, which AFAIK only specifies the first line.

When there's a widely-used standard in question, "worse is better" if
better doesn't conform.  This particular standard is respected by more
than just Emacs.

 > Are you aware that gfortran can report errors that span multiple lines?

That's irrelevant; there are any number of ways to format arbitrarily
complex error information and remain GNU-conforming.

With respect to this capability per se, while it sounds like a useful
innovation, you'd have to show me an example to convince me that most
messages concerning errors that span multiple lines would not benefit
greatly from being unpacked into a series of messages explaining line
by line what the compiler thinks went wrong.  If so, there's very
little cost to a simple terse header that conforms to the standard.
The readability cost is actually greater for messages that refer to
only one line, IMO!

Note that gcc does things more powerful than that already, without
extending the error syntax standard.  For example it will warn about a
redefined macro on one line, and then tell you where the original
definition was, even in a different file, on the next.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]