all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* RE: Can't build latest emacs on MSW + CRLF display issue
@ 2013-08-25 18:54 Vincent Belaïche
  2013-08-25 19:33 ` Eli Zaretskii
  0 siblings, 1 reply; 17+ messages in thread
From: Vincent Belaïche @ 2013-08-25 18:54 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Karl Berry, emacs-devel



> 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.



^ permalink raw reply	[flat|nested] 17+ messages in thread
* Re: Can't build latest emacs on MSW + CRLF display issue
@ 2013-08-27  2:44 Vincent Belaïche
  0 siblings, 0 replies; 17+ messages in thread
From: Vincent Belaïche @ 2013-08-27  2:44 UTC (permalink / raw)
  To: Eli Zaretskii, Glenn Morris; +Cc: Karl Berry, emacs-devel

Hello Glenn,

> From: rgm@gnu.org
> To: eliz@gnu.org
> Subject: Re: Can't build latest emacs on MSW + CRLF display issue
> Date: Mon, 26 Aug 2013 21:46:03 -0400
> CC: emacs-devel@gnu.org
> 
> 
> I'm not trying to be difficult here, I really just don't understand
> your logic.
> 
> Reasons to remove the old method:
> 1) It's unsupported and out-of-date (eg I know it doesn't build all the
> manuals. Minor but still a bug.).
> 
> 2) There's no need to have two separate methods to build Emacs on
> MS Windows.
> 
> 3) The new method is obviously preferable since it is the same method
> used on all other platforms (except MS DOS).
> 
> Even if 1) changes (and it shows no sign of doing so), 2) and 3) never will.
> 
> 
> On the other hand, I can't think of a single reason to _not_ remove it.
> 
> If someone turns up and wants to do 1), it will be the least of their
> problems to first revert the commit that removed the old method. (But
> we should not let them anyway, because of 2 and 3.)
> 
> 
> (BTW, I suggest at least renaming nt/INSTALL to nt/INSTALL.OLD, and
> INSTALL.MSYS to INSTALL.)
> 

Not sure whether this email above was addressed to me or to Eli. Sorry
if I did something wrong with adding the user's confirmation in the
configure.bat.

Is that your concern ?

I was just trying to stick better to your original proposal (big fat
warning + user's confirmation to go on at his/her own risks). Maybe I
misinterpreted what you suggested, as I had not followed the full
discussion on building for MSW.


   Vincent.

PS-1: Personnally I don't mind if the .bat file is removed. But at least
keeing it has the advantage that if a user --- like me --- used his/her
legacy own MSDOS script to do all the job of

- update the source
- configure PATH for the build to work properly
- launch configure.bat with all the wanted options and then make

then this user will receive a clear warning why this old automated way
won't work, so he/she can easily update his script (or rather rewrite it
fully as a BASH script) to use the new build method. And therefore this
user will be less likely to come to this forum like I did and bother
everyone with questions.

PS-2: Your suggestion to rename the INSTALL files is excellent.



^ permalink raw reply	[flat|nested] 17+ messages in thread
* Re: Can't build latest emacs on MSW + CRLF display issue
@ 2013-08-27  2:28 Vincent Belaïche
  0 siblings, 0 replies; 17+ messages in thread
From: Vincent Belaïche @ 2013-08-27  2:28 UTC (permalink / raw)
  To: Eli Zaretskii, Glenn Morris; +Cc: Karl Berry, emacs-devel

Eli Zaretskii a écrit :
>> From: vincent.belaiche@gmail.com (Vincent Belaïche)
>> Cc: emacs-devel@gnu.org, Karl Berry <karl@freefriends.org> 
>> Date: Mon, 26 Aug 2013 08:06:08 +0200
>>
>> BTW, it still does not compile, even with INSTALL.MSYS way I have the
>> cl-member function definition is void error message.
>>
>> -----------------------------------------------------------------------
>> Wrote c:/Programme/GNU/installation/emacs-install/emacs/trunk/lisp/progmodes/meta-mode.elc
>> Compiling progmodes/mixal-mode.el
>> Wrote c:/Programme/GNU/installation/emacs-install/emacs/trunk/lisp/progmodes/mixal-mode.elc
>> Compiling progmodes/modula2.el
>>
>> In toplevel form:
>> progmodes/modula2.el:113:1:Error: Symbol's function definition is void: cl-member
>> make[2]: *** [progmodes/modula2.elc] Error 1
>
> Did you try removing smie.elc and saying "make" again?
>

[...]

Thanks, that has worked, and it reconfirmed that if ever any remaining
issue with ^M display, that is impossible for me to reproduce.

BR,
   Vincent.



^ permalink raw reply	[flat|nested] 17+ messages in thread
* RE: Can't build latest emacs on MSW + CRLF display issue
@ 2013-08-26  6:06 Vincent Belaïche
  2013-08-26 13:12 ` Eli Zaretskii
  0 siblings, 1 reply; 17+ messages in thread
From: Vincent Belaïche @ 2013-08-26  6:06 UTC (permalink / raw)
  To: Eli Zaretskii, rgm; +Cc: Karl Berry, emacs-devel

>
>
>From: vincent.b.1@hotmail.fr
>To: rgm@gnu.org; eliz@gnu.org
>Subject: RE: Can't build latest emacs on MSW + CRLF display issue
>Date: Sun, 25 Aug 2013 22:18:57 +0200
>CC: karl@freefriends.org; emacs-devel@gnu.org
>
>
>
>> From: rgm@gnu.org
>> To: eliz@gnu.org
>> Subject: Re: Can't build latest emacs on MSW + CRLF display issue
>> Date: Sun, 25 Aug 2013 15:40:44 -0400
>> CC: vincent.b.1@hotmail.fr; emacs-devel@gnu.org; karl@freefriends.org
>> 
>> Eli Zaretskii wrote:
>> 
>> >> If you don't want to remove this old method (I really don't get this,
>> >> but we've been over this before), can it at least print a big fat
>> >> warning when it starts, maybe even with a "press return to continue at
>> >> your own risk" or somesuch. (Maybe it does this already.)
>> >
>> > Feel free to add that, I don't want to invest even a few seconds of my
>> > time on this. 
>> 
>> I'd much rather remove it all together, but you won't allow it.
>> Therefore we are stuck in this state.
>> 
>
>I took the freedom to make it a little more elaborate to stick to
>Glenn's first idea to have some kind of confirmation request and BIG
>FAT warning.
>
>Well, it happened that when I wanted to commit my change I realized
>that Glenn had already done it, and so I just merged what I had done.
>
>   Vincent.

BTW, it still does not compile, even with INSTALL.MSYS way I have the
cl-member function definition is void error message.

-----------------------------------------------------------------------
Wrote c:/Programme/GNU/installation/emacs-install/emacs/trunk/lisp/progmodes/meta-mode.elc
Compiling progmodes/mixal-mode.el
Wrote c:/Programme/GNU/installation/emacs-install/emacs/trunk/lisp/progmodes/mixal-mode.elc
Compiling progmodes/modula2.el

In toplevel form:
progmodes/modula2.el:113:1:Error: Symbol's function definition is void: cl-member
make[2]: *** [progmodes/modula2.elc] Error 1
make[2]: Leaving directory `/c/Programme/GNU/installation/emacs-install/emacs/trunk/lisp'
make[1]: *** [compile-main] Error 2
make[1]: Leaving directory `/c/Programme/GNU/installation/emacs-install/emacs/trunk/lisp'
make: *** [lisp] Error 2
-----------------------------------------------------------------------

Maybe modula2.el misses some declare-function or (eval-when-compile
(require 'cl)) statement...

   Vincent.



^ permalink raw reply	[flat|nested] 17+ messages in thread
* Can't build latest emacs on MSW + CRLF display issue
@ 2013-08-25 11:52 Vincent Belaïche
  2013-08-25 15:02 ` Eli Zaretskii
  0 siblings, 1 reply; 17+ messages in thread
From: Vincent Belaïche @ 2013-08-25 11:52 UTC (permalink / raw)
  To: emacs-devel; +Cc: Karl Berry

[-- Attachment #1: Type: text/plain, Size: 1676 bytes --]

Hello,

I have been trying to build the latest emacs on MSWindowsXP + MinGW and
I came across the following issues:

- during the build I get the following error message

In toplevel form:
url/url-proxy.el:24:1:Error: Symbol's function definition is void: cl-member


- during the make-install I get the following error message

gcc -o oo-spd/i386/profile.exe  -gdwarf-2 -g3    oo-spd/i386/profile.o ../lib/oo-spd/i386/libgnu.a oo-spd/i386/ntlib.o   -ladvapi32
mingw32-make.exe[1]: Leaving directory `C:/Programme/GNU/installation/emacs-install/emacs/trunk/lib-src'
mingw32-make.exe[1]: *** No rule to make target `../lisp/international/mule.elc', needed by `DOC'.  Stop.
mingw32-make.exe: *** [all-other-dirs-gmake] Error 2


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.

My feeling is that there is some inconsistency, but maybe I
misunderstood the criterion that triggers ^M hiding.

Both info files have consistent CRLF endings which I checked with the
attached eol_status.cpp tool.

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.

VBR,
   Vincent.


[-- Attachment #2: eol_status.cpp --]
[-- Type: text/plain, Size: 1256 bytes --]

#include <iostream>
#include <fstream>
#include <cstring>
#include <string>
using namespace std;


int main(int ac,char const* av[])
{
  if(ac < 2){
	cerr << "Usage: eol_status [FILE]";
	return -1;
  }
  ifstream in(av[1],ios_base::binary);
  if(!in.is_open()){
	cerr << "Can't open file ``"<<av[1]<<"''\n";
	return -2;
  }

  int prev_char = EOF;
  int cur_char;

  int cr_count = 0;
  int lf_count = 0;
  int crlf_count = 0;
  while((cur_char = in.get()) != EOF){
	if(cur_char == 10){
	  if(prev_char == 13)
		++crlf_count;
	  else
		++lf_count;
    }
	else if(prev_char == 13)
      ++cr_count;
	prev_char = cur_char;
  }
  if(prev_char == 13)
	++cr_count;

  if(cr_count != 0 && lf_count == 0 && crlf_count == 0)
	cout << cr_count <<" ends of line are in CR\n";
  else if(cr_count == 0 && lf_count != 0 && crlf_count == 0)
	cout << lf_count <<" ends of line are in LF\n";
  else if(cr_count == 0 && lf_count == 0 && crlf_count != 0)
	cout << crlf_count <<" ends of line are in CRLF\n";
  else  if(cr_count == 0 && lf_count == 0 && crlf_count == 0)
	cout << "Zero end of line\n";
  else
	cout << "Inconsistent end of lines:\n\tCR count   = "<<cr_count
		 << "\n\tLF count   = "<<lf_count
		 << "\n\tCRLF count = "<<crlf_count
		 << "\n";

  return 0;
}

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2013-08-27 19:11 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-08-25 18:54 Can't build latest emacs on MSW + CRLF display issue Vincent Belaïche
2013-08-25 19:33 ` Eli Zaretskii
  -- strict thread matches above, loose matches on Subject: below --
2013-08-27  2:44 Vincent Belaïche
2013-08-27  2:28 Vincent Belaïche
2013-08-26  6:06 Vincent Belaïche
2013-08-26 13:12 ` Eli Zaretskii
2013-08-25 11:52 Vincent Belaïche
2013-08-25 15:02 ` Eli Zaretskii
2013-08-25 19:00   ` Glenn Morris
2013-08-25 19:27     ` Eli Zaretskii
2013-08-25 19:40       ` Glenn Morris
2013-08-25 20:18         ` Vincent Belaïche
2013-08-25 20:36         ` Eli Zaretskii
2013-08-27  1:46           ` Glenn Morris
2013-08-27 15:20             ` Eli Zaretskii
2013-08-27 18:54               ` Glenn Morris
2013-08-27 19:11                 ` Eli Zaretskii

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.