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.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1349





------- Comment #1 from felipe.contreras@gmail.com  2007-07-20 03:18 -------
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.


-- 

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

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

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

http://d.puremagic.com/issues/show_bug.cgi?id=1349


bugzilla@digitalmars.com changed:

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




------- Comment #3 from bugzilla@digitalmars.com  2007-07-23 02:28 -------
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).


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1349





------- Comment #4 from thomas-dloop@kuehne.cn  2007-07-23 14:56 -------
(In reply to comment #3)
> 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.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1349





------- Comment #5 from bugzilla@digitalmars.com  2007-07-23 18:43 -------
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.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1349


felipe.contreras@gmail.com changed:

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




------- Comment #6 from felipe.contreras@gmail.com  2007-07-23 19:03 -------
(In reply to comment #3)
> 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.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1349


bugzilla@digitalmars.com changed:

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




------- Comment #7 from bugzilla@digitalmars.com  2007-07-23 19:34 -------
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 :-)


--