From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?iso-8859-1?Q?Vincent_Bela=EFche?= Newsgroups: gmane.emacs.devel Subject: RE: Can't build latest emacs on MSW + CRLF display issue Date: Sun, 25 Aug 2013 20:54:01 +0200 Message-ID: <80haed61py.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1377456878 23362 80.91.229.3 (25 Aug 2013 18:54:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 25 Aug 2013 18:54:38 +0000 (UTC) Cc: Karl Berry , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 25 20:54:41 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VDfSS-0000Pm-S8 for ged-emacs-devel@m.gmane.org; Sun, 25 Aug 2013 20:54:41 +0200 Original-Received: from localhost ([::1]:47326 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VDfSS-00012T-8T for ged-emacs-devel@m.gmane.org; Sun, 25 Aug 2013 14:54:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43670) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VDfSM-00011W-59 for emacs-devel@gnu.org; Sun, 25 Aug 2013 14:54:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VDfSH-0004fj-Gd for emacs-devel@gnu.org; Sun, 25 Aug 2013 14:54:34 -0400 Original-Received: from smtp11.smtpout.orange.fr ([80.12.242.133]:57007 helo=smtp.smtpout.orange.fr) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VDfSH-0004fd-6H for emacs-devel@gnu.org; Sun, 25 Aug 2013 14:54:29 -0400 Original-Received: from CHOUNEK ([92.135.119.244]) by mwinf5d21 with ME id H6uS1m00G5GUJNL036uTnV; Sun, 25 Aug 2013 20:54:27 +0200 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.12.242.133 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:163014 Archived-At: > Date: Sun, 25 Aug 2013 18:02:51 +0300 > From: eliz@gnu.org > Subject: Re: Can't build latest emacs on MSW + CRLF display issue > To: vincent.b.1@hotmail.fr > CC: karl@freefriends.org; emacs-devel@gnu.org > [...] > > 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.