Vincent Belaïche a écrit :
Gavin Smith a écrit :
On Mon, Sep 1, 2014 at 7:15 PM, Vincent Belaïche
[...]
Dear Gavin et alii,
I think that you have put the finger on it: it does not have to do
with @include but with line endings. I did the following experiment:
* both bug_texinfo.texi and bug_texinfo-macros.texi in Unix file
endings => no problem at all for any of the two macros.
* both bug_texinfo.texi and bug_texinfo-macros.texi in DOS file
endings => problem exists for both macros, that which is in the main
file, and that which is in the included file.
Conclusion: texi2any macro parser has a problem with handling line
endings when it removes the last line end before @end macro. I suspect
that if the coding is consistent the same problem exists with removal
of the first line ending after @macro.
VBR,
Vincent.
Just as a few side comments:
* it is probably worth checking whether @rmacro has the same issue
* probably the perl script uses some hard-coded "\n", rather than some
`endofline' property of the file from which the macro was read.
* it would be good if it is not mandatory that all files used for a
single document have the same format, because in any collaborative
project there may be guies with DOS and others with Unix working
together (and even the same guy with two different machine, being DOS in
the morning, and unix in the afternoon). There is also the following
issue that when a doc is under version control, some of the files may be
set as binary in the repo for some reason, and others not, so people say
on Unix will get consistent line ending, and people say on DOS won't get
that because the non-binary files won't have end-of-line conversion by
the version control, while others will have it. I do not argue that it
is desirable that users are consistent, just suggesting that texi2any
could do that at a moderate cost, and that would make life easier for
everybody. The only rule should be that *within a same file* you have to
be consistent.
VBR,
Vincent.
Vincent.
