Re: [bug #43126] Macros defined through @include make a spurious space before @end macro

[Vincent Belaïche]

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.