RE: Can't build latest emacs on MSW + CRLF display issue

[Vincent Belaïche]

> Date: Sun, 25 Aug 2013 18:02:51 +0300
> From: address@hidden
> Subject: Re: Can't build latest emacs on MSW + CRLF display issue
> To: address@hidden
> CC: address@hidden; address@hidden
> 

[...]

> 
> This method of building Emacs on Windows is deprecated and slowly
> bitrots. See nt/INSTALL.MSYS for the supported method.
> 

Ok, I will try that using the autoconf and automake from ezwinports. 

BTW there are also autoconf & automake under the sourceforge mingw
project, but with lesser version number. Your files are for MSYS not
MINGW, right ? And they need the MSYS perl, not the e.g. activestate
perl.

Maybe INSTALL.MSYS should be a bit more talkative about that.

> Or, if, as I'm guessing, you don't really want to build Emacs, just to
> try a recent development snapshot, use one of the places where
> precompiled binaries are available (they were announced on this list
> not too long ago).

Sorry for I missed that. It is true that I was just trying to get a
recent version, but anyway if I can make a build, it is even better.

> 
> > Anyway, the build has gone far enough so that I have an emacs.exe with
> > the latest source, and it confirmed a problem which I had with my
> > previous build, the display of ^M at ends of lines seems buggy:
> > 
> > Here are two pictures:
> > 
> > http://savannah.gnu.org/bugs/download.php?file_id=28919
> > http://savannah.gnu.org/bugs/download.php?file_id=28920
> > 
> > Both pictures concern visiting info files, but the first one (cr.info)
> > has the ^M hidden, and the second one (bbdb.info) has the ^M shown.
> 
> The first one, cr.info, doesn't have ^M characters at all, as
> evidenced by the "/" mnemonics at the left corner of the mode line.
> 

It is a `\' not a `/' mnemonic on the PNG picture, which shows that
cr.info contains consistent CRLF characters, which are not displayed,
because as you are stating later on, cr.info is deemed to be a text file
by EMACS.

I just had a wink at the manual, the eol converion is displayed in mode
line after the coding scheme, like this:

- `:' or `(Unix)' for LF 
- `\' or `(DOS)' for CRLF 
- `/' or (Mac) for CR


> > My feeling is that there is some inconsistency, but maybe I
> > misunderstood the criterion that triggers ^M hiding.
> 
> If Emacs shows the ^M characters, it means that either (a) the EOL is
> inconsistent, or (b) Emacs decided that the file is binary.  In your
> case, the "=" at the left of the mode line suggests the latter
> possibility. Without looking at the file in its entirety, I cannot
> tell why that could be the case.
> 

I agree it is (b) for bbdb.info, I checked that bbdb.info is
consistently encoded with CRLF by using hexl-mode, and then by writing
some eol_status.cpp short program as hexl was not so practical.

So bbdb.info is seen as a binary file using LF end-of-line. That is a
bit surprising given the very large majority of printable characters it
constains.

> > Both info files have consistent CRLF endings which I checked with the
> > attached eol_status.cpp tool.
> 
> The best way of checking is to visit the file with
> "M-x find-file-literally", then looking for lines that end in ^J
> without a ^M.

Thanks for the trick !

> 
> > I must say also that I met a problem on bbdb.info which then I could
> > never reproduce: at some point of time it was displayed w/o the ^M at
> > for almost the whole file except in the last few tens lines where the ^M
> > endings were displayed.
> 
> I suspect that you are producing these Info files in some strange
> way. Perhaps you mix MSYS and MinGW programs, such as install-info
> and Perl, or something else. Mixing MSYS and native programs is known
> to produce strange effects wrt EOL format.
> 

Well, it is true that I was doing some not so orthodox things, and I
also thought in the beginning that Texinfo was the one to blame. There
was two reasons for that:
- I had already met such kind of issue in the past, especially in the
  INFO-DIR-SECTION
- I was not aware that EMACS could make some decision that an info file
  is a binary file and force ^M display even if EOL's are
  consistent. What surprised me was that info files may be handled
  either like text file, or like binary files depending on the constent.
- I must admit that I was not enough paying attention to the more line.

> Anyway, given the long thread on bug-texinfo about related issues,
> what exactly is the purpose of this discussion? 
> If you think there's a bug in Emacs's Info reader, 

No problem with the info reader, that was happening with visiting the
info files. Viewing them like info is perfect.

I was visiting them to check the EOL consistency because as I wrote I
already had issues with that.

At some point of time I got some display that the beginning of file has
no ^M displayed and the end of file has. 

Unfortunately I could not reproduce this, and I did not take any screen
capture, because I was thinking the problem was from the file itself,
and not its displaying. 

I am now almost sure that the files were always the same, but since I
could not reproduce the issue in neither way I cannot be 100% sure.

I have experienced that with a 2013-04-08 build of EMACS, and my only
objective was to make you know about it: Karl informed me that there
already was such kind of ^M display issues. This is why I wanted to make
you know.

> then please provide the shortest Info file that can be used to
> reproduce the problem, starting with "emacs -Q".  If your goal is
> something else, please state what that is.
> 

I am not asking for anything, my sole goal was to inform you, and I
cannot provide more information than is in this email. If ever I can
reproduce that I will be more careful and try to get a screen capture
for you.

> Thanks.
> 
>
Thank you very much for the hint at the new way to build. And sorry for
the much ado for so little a thing.

   Vincent.