bug-texinfo
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #46018] texi2any makes inconsistent EOL style


From: Vincent Belaïche
Subject: [bug #46018] texi2any makes inconsistent EOL style
Date: Sun, 27 Sep 2015 18:34:25 +0000
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko

Follow-up Comment #3, bug #46018 (project texinfo):

I just realized that we have already discussed this sort of EOL conversion in
relation with [bug #38795]. In [bug #38795] my problem was that the BBDB
manual was made of several files, some of them had svn:eol-style set to LF and
others to native becoming CRLF for MSW users, so when compiling the source
with makeinfo I also had inconsistent EOL's in the output.

I try to summarize the discussion that had happened below:

* Patrice said there was not any intention to make any EOL conversion, and if
it happens, it is by accident (cf 2013-04/msg00016
<http://lists.gnu.org/archive/html/bug-texinfo/2013-04/msg00016.html>)

* Karl (cf 2013-04/msg00020
<http://lists.gnu.org/archive/html/bug-texinfo/2013-04/msg00020.html> said
that Texinfo should not canonicalize the input EOL's, but the user has to use
input files and tools with consistent EOL style, so this was a bug in BBDB
manual version control, they should have had the same eol-style property

* Eli said CRLF EOL must be supported on MSW (cf 2013-04/msg00017
<http://lists.gnu.org/archive/html/bug-texinfo/2013-04/msg00017.html>), my
understanding that LF only was to be used was based on a misleading doc which
has probably been corrected since then. 

So in a nutshell, the consensus that was to use tools with EOL-style
consistent with the input files. This was against my opinion that either some
input EOL canonicalization has to be done by Texinfo tools, or Texinfo source
code should use only LF.

Then, with this consensus which seemingly has not changed, I am wondering how
it can work in the following situation:

* I get some Texinfo source code from project A, and project A people have
decided to set svn:eol-style to LF for Texinfo files, so I am supposed to
compile thes files with MSYS perl, the output file will be in LF, so their
svn:eol-style need to be also set to LF.

* I get some Texinfo source code from project B, and project B people have
decided to set svn:eol-style to native for Texinfo files, so I am supposed to
compile thes files with native perl. The output files will be in native (CRLF
on MSW), so their svn:eol-style need to be also set to LF.

* I could also use a native perl to compile files with LF EOL's, the output
will have consistent CRLF EOL's, so that will raise some problem if it is
version controlled and has, like input svn:eol-style set to LF

In conclusion, if I want to work both on project A and project B, I need two
texi2any wrappers, one using MSYS perl for project A, and one using native
perl for project B. This is not very practical.

The only practical way, indeed, would be that project B people set the EOL
style property to LF in their source control, which anyway will have no impact
on Linux users. So, it would be that Texinfo source code is always LF-EOL'ed

Please note that I am not even sure that it is possible to install texi2any on
MSW with a native perl, as far as the installation scripts are MSYS based. In
fact, I am using a non installed texi2any with interpreting the perl code in
its source directory either with a native perl or an MSYS perl. Using a non
installed texi2any raises some problem for the locales ; but that is another
issue.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?46018>

_______________________________________________
  Message posté via/par Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]