Re: 125-better-file-contents.patch

[Tom Tromey]

>>>>> "Akim" == Akim Demaille <address@hidden> writes:

Akim> Still getting closer to what Tom doesn't want: the read_am_file
Akim> removal.  I would be lying if I pretended that this removal was
Akim> easy: pretty many weaknesses in file_contents weaknesses are
Akim> uncovered by the test suite when you replace read_am_file with
Akim> file_contents.

Akim> But I'm very confident.

I'm still not.  That's why I'm reluctant to look at 124- and 125-.

Akim> More precisely, I have problems with keeping line numbers
Akim> sync'ed in error messages.  I understand fairly well this is a
Akim> good service to provide to the user, but it's somewhat in
Akim> opposition with the most (in my own definition of the word)
Akim> natural implementation of file_contents.

I think it is crucial to give good line numbers in errors.  People
find automake cryptic enough already.  Giving incorrect line numbers
in errors will make this problem worse.

Akim>   ifeq ("${APACHE_DIR_IS_SRC}","yes")
Akim>   SUBDIRS = java
Akim>   else
Akim>   SUBDIRS = c java
Akim>   endif

I like your reasoning about this.  However, does your plan of using
make_paragraphs work even if the user inserts whitespace?  Suppose I
add a newline between each pair of lines in your example.  Does the
paragraph separation still work?  If not then it can't really be
considered reliable...

Akim>   verbatim
Akim>   ifeq ("${APACHE_DIR_IS_SRC}","yes")
Akim>   SUBDIRS = java
Akim>   else
Akim>   SUBDIRS = c java
Akim>   endif
Akim>   end verbatim

This is interesting.  I wonder if users would expect automake not to
look at the contents of verbatim at all?  E.g., in the above SUBDIRS
would be considered as not defined?  That is easy from an
implementation point of view.  But from the user's point of view it
might be painful.

Tom