www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 1349] New: ^M pollution

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1349

           Summary: ^M pollution
           Product: D
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: trivial
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: felipe.contreras gmail.com


Following 268#c17

Basically the whole code is badly formated. Probably in Windows there isn't
much trouble, but in Linux ^M are visible at the eol everywhere.

If the this implementation of D wants to be taken seriously these kinds of
issues shouldn't happen.


--
Jul 20 2007
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1349






AFAIK D is used mostly on the Windows realm, right? Perhaps there are issues
similar like this one that will make it more popular in Linux.


--
Jul 20 2007
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
<d-bugmail puremagic.com> wrote in message 
news:bug-1349-3 http.d.puremagic.com/issues/...

 Basically the whole code is badly formated. Probably in Windows there 
 isn't
 much trouble, but in Linux ^M are visible at the eol everywhere.

 If the this implementation of D wants to be taken seriously these kinds of
 issues shouldn't happen.


Solution: don't use emacs.

Any editor that doesn't understand more than one line ending convention 
isn't worth anything IMO.  That includes notepad under Windows, to be fair.
Jul 20 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Jarrett Billingsley wrote:

 <d-bugmail puremagic.com> wrote in message 
 news:bug-1349-3 http.d.puremagic.com/issues/...

 Basically the whole code is badly formated. Probably in Windows there 
 isn't
 much trouble, but in Linux ^M are visible at the eol everywhere.

 If the this implementation of D wants to be taken seriously these kinds of
 issues shouldn't happen.


 
 Solution: don't use emacs.
 
 Any editor that doesn't understand more than one line ending convention 
 isn't worth anything IMO.  That includes notepad under Windows, to be fair. 


If you see ^M's everywhere in emacs that means that one or more lines 
are without ^M's.  Emacs work fine with files that have consistent line 
endings.

--bb
Jul 20 2007
parent Sean Kelly <sean f4.ca> writes:
Bill Baxter wrote:

 
 If you see ^M's everywhere in emacs that means that one or more lines 
 are without ^M's.  Emacs work fine with files that have consistent line 
 endings.


Line endings are mixed in Phobos.  I have to clean this up in Tango 
after every code merge (Tango uses SVN's conversion filter and rejects 
any commit with non-native line endings).
Jul 20 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1349


bugzilla digitalmars.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID





Modern text processing software should accept the following as line
terminations:

LF (unix)
CR (mac)
CRLF (windows, DEC)

It isn't just a unix world. gnumake used to fail on CR's a few years ago, that
got fixed. gcc works on those line endings, so does all Digital Mars software.
If you are using software that doesn't recognize common line terminations, that
is a bug in that software, not the text file. Since D source code is portable
between operating systems, it cannot be required to use just one protocol.

If you need an editor that works properly, see microEmacs (downloadable from
digitalmars.com).


--
Jul 23 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1349








 Modern text processing software should accept the following as line 


terminations:

 
 LF (unix)
 CR (mac)
 CRLF (windows, DEC)



 If you are using software that doesn't recognize common line terminations, 


that is a bug in that software, not the text file.

Correct. However the real issue are the Phobos and DMD-frontend sources shipped 
with GDC. They use a mix of different line endings within a single file. That 
kind of EOL mixing can cause serious trouble if the code is e.g. cut-n-pasted 
into another application.


--
Jul 23 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1349






I'm still going to argue that any "serious problems" this causes are bugs in
those other programs. It's entirely reasonable that source text files are
editted on multiple systems with different line ending rules, and so any
program that processes them ought to handle it.


--
Jul 23 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1349


felipe.contreras gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |







 Modern text processing software should accept the following as line
 terminations:
 
 LF (unix)
 CR (mac)
 CRLF (windows, DEC)
 
 It isn't just a unix world. gnumake used to fail on CR's a few years ago, that
 got fixed. gcc works on those line endings, so does all Digital Mars software.
 If you are using software that doesn't recognize common line terminations, that
 is a bug in that software, not the text file. Since D source code is portable
 between operating systems, it cannot be required to use just one protocol.
 
 If you need an editor that works properly, see microEmacs (downloadable from
 digitalmars.com).
 


I'm using vim aka. "an editor that works properly".

This isn't a UNIX world, but most serious development at the level that D is
aiming is done in UNIX. So it's funny that you have DOS line endings, while as
you say: modern text processing software should accept all the line endings.

Professional text editors should not mix line endings. Whatever text editor
introduced those glitches it surely runs on Windows, and the whole thing simply
looks bad.

Forgetting about the UNIX vs Windows stuff there are advantages of just LF:
* Less space
* Easier processing

For example:
 perl -spi -e 's/\r//' $file

That would solve all the issues (transform to LF). I would love to see how
"easy" it would be the line to transform everything to CRLF.

BTW, these are the files that are wrong:
./phobos/internal/arraycat.d
./phobos/internal/gc/gc.d
./phobos/internal/critical.c
./phobos/std/math.d
./phobos/std/socket.d
./phobos/std/format.d
./dmd/constfold.c
./dmd/template.c
./dmd/html.c

I found them with:
 grep -P '\r[^\n]' -l -r .

This is on the GDC official tarball.


--
Jul 23 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1349


bugzilla digitalmars.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |INVALID





If vim isn't handling mixed line endings, then it doesn't work properly.

Whatever advantages LF might have simply do not matter, as there are systems in
wide use that use other conventions, and people ARE going to mix them up, and
they SHOULD work. Line ending parochialism, and the debate about which one
should prevail, ended about 15 years ago. Programmers simply decided to write
their software to accept all three conventions and moved on to argue about more
important things like { } style.

Gnu has fixed gnumake, gcc, and other text processing software to work right.
There's little reason to indulge obsolete software that doesn't. Submit bug
reports for them.

BTW, microEmacs (what I use) reads all three conventions agnostically, as do
all DM products. It emits CRLF when on Windows, and LF when on Linux, for all
lines. It does not mix the conventions on output - so if on the GDC tarball
there are mixed conventions in the same file, it is not due to my edits.
Someone probably used vim on it :-)


--
Jul 23 2007
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1349








 If vim isn't handling mixed line endings, then it doesn't work properly.


That's debatable.


 Whatever advantages LF might have simply do not matter, as there are systems in
 wide use that use other conventions, and people ARE going to mix them up, and
 they SHOULD work. Line ending parochialism, and the debate about which one
 should prevail, ended about 15 years ago. Programmers simply decided to write
 their software to accept all three conventions and moved on to argue about more
 important things like { } style.


Did it?

Just search for "^m character" on Google, and you'll find that the solution is
remove all the CR's.


 Gnu has fixed gnumake, gcc, and other text processing software to work right.
 There's little reason to indulge obsolete software that doesn't. Submit bug
 reports for them.


Work "right" is something you are defining. Surely Firefox does some things to
work better for sites that use bad standards but work fine on IE, that is not
exactly "right". BTW, your bugzilla doesn't render correctly on Firefox.


 BTW, microEmacs (what I use) reads all three conventions agnostically, as do
 all DM products. It emits CRLF when on Windows, and LF when on Linux, for all
 lines. It does not mix the conventions on output - so if on the GDC tarball
 there are mixed conventions in the same file, it is not due to my edits.
 Someone probably used vim on it :-)


Vim emits CRLF when you tell it to, LF when you tell it to. It will add CRLF
when the rest of the file has CRLFs, it will add LFs when the rest of the file
has LFs, and it will "properly" (according to me and a whole lot of people)
show where there's a mixing issue.

Mix line endings, mix shifts with tabs and spaces, do whatever you want and
ignore how it will look on other people's editors, it's your choice.

Vim _is_ operating system _and_ file format agnostic.

You attack Vim---one of the most important text editors out there, if not the
most---, saying that Vim not working properly. You use DOS file format. You
don't provide a debugger to use under any OS except Win32. On the menu, right
after Overview you have "D for Win32" and "Win32 DLLs in D". You provide your
files in Zip format available either for "Win32 and Linux" or "Win32".

Your D implementation is _not_ operating system agnostic, it's really biased to
one.

And finally, CR is not the default in mac as you say, it was, until version 9.
According to Wikipedia [1], Windows is the only operating system today that
uses anything else than LF.

[1] http://en.wikipedia.org/wiki/Newline


--
Jul 25 2007