Re: 125-better-file-contents.patch

[Akim Demaille]

>>>>> "Tom" == Tom Tromey <address@hidden> writes:

>>>>> "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.

Tom> I'm still not.  

:)  I know.  Anyway I don't plan to do this soon.

Tom> That's why I'm reluctant to look at 124- and 125-.

I understand.  In fact, I have already applied them, I had not
realized you might want to refuse them.  I did so because anyway it
does not do what you don't want me to.

124 is really basically cleaning naming issues, and provides better
error messages in some situations.

125 is addressing only file_contents so it is definitely safe.


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.

Tom> I think it is crucial to give good line numbers in errors.

I definitely agree, that's why I rose this issue.  It is a show
stopper for the merging.



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

What I mean by paragraph does not necessarily really mean paragraph in
the sense of Make.  For instance a rule with several Automake if/endif
inside is composed of several paragraphs.

As a matter of fact, I _had_ to introduce paragraphs because of things
like subdirs.am where you need to swallow several lines before seeing
the `:' and then finally be able to conclude you're reading a rule.

But if there are better approaches, I'm fine with them.


Akim> verbatim ... end verbatim

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

IMHO verbatim is verbatim, i.e., absolutely opaque to automake.  We
can always @strong this in the documentation, but automake should not
even try to warn the user about possible unintended alteration of
Automake entities.  It's opaque, period.