Are there any plans to fix the bug where ASCII 10 by-itself (without 13) is not recognised as an enter?  Otherwise could charles put something in DIDE so ASCII 10 by themselves are fixed?  At the moment I'm resorting to copying into mozilla and pasting back into DIDE.  I suppose I could write a filter, but that wouldn't work with DIDE.

Anderson

Hmm im not sure this is a bug.  Windows convention is to use \r\n as new line  , where unix is \n alone.  I can add a translate newline function ?

C


"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message news:bth8dq$1ra0$1@digitaldaemon.com...
> Are there any plans to fix the bug where ASCII 10 by-itself (without 13) is not recognised as an enter?  Otherwise could charles put something in DIDE so ASCII 10 by themselves are fixed?  At the moment I'm resorting to copying into mozilla and pasting back into DIDE.  I suppose I could write a filter, but that wouldn't work with DIDE.
>
> Anderson
>

C wrote:

>Hmm im not sure this is a bug.  Windows convention is to use \r\n as new
>line  , where unix is \n alone.  I can add a translate newline function ?
>
>C
>
>  
>
That would be cool.  It would be nice, if you could simply detect it when saving or copy/pasting although their's be an associated performance hit. 

What if your trying to compile a unix program in windows?   I don't see why the compiler can't treat \n as an enter, (dare I say it) even as a compiler switch. It could be part of the D compiler standard to treat both \n and \r\n the same, as most windows editors do.  This is particularly problematic when copying from VS which happens to use \n.  I think it'll put many new users off if something isn't done about it.

Anderson

>"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message
>news:bth8dq$1ra0$1@digitaldaemon.com...
>  
>
>>Are there any plans to fix the bug where ASCII 10 by-itself (without 13)
>>is not recognised as an enter?  Otherwise could charles put something in
>>DIDE so ASCII 10 by themselves are fixed?  At the moment I'm resorting
>>to copying into mozilla and pasting back into DIDE.  I suppose I could
>>write a filter, but that wouldn't work with DIDE.
>>
>>Anderson
>>
>>    
>>
>
>
>  
>

Hmm  where are you copying from to get this behavior ?  I copy from VS and it looks ok.  There is a way to convert automatically, just need something to test it with.

Thanks,
C
"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message
news:bthjic$2cmn$1@digitaldaemon.com...
> C wrote:
>
> >Hmm im not sure this is a bug.  Windows convention is to use \r\n as new line  , where unix is \n alone.  I can add a translate newline function ?
> >
> >C
> >
> >
> >
> That would be cool.  It would be nice, if you could simply detect it when saving or copy/pasting although their's be an associated performance hit.
>
> What if your trying to compile a unix program in windows?   I don't see why the compiler can't treat \n as an enter, (dare I say it) even as a compiler switch. It could be part of the D compiler standard to treat both \n and \r\n the same, as most windows editors do.  This is particularly problematic when copying from VS which happens to use \n. I think it'll put many new users off if something isn't done about it.
>
> Anderson
>
> >"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message news:bth8dq$1ra0$1@digitaldaemon.com...
> >
> >
> >>Are there any plans to fix the bug where ASCII 10 by-itself (without 13) is not recognised as an enter?  Otherwise could charles put something in DIDE so ASCII 10 by themselves are fixed?  At the moment I'm resorting to copying into mozilla and pasting back into DIDE.  I suppose I could write a filter, but that wouldn't work with DIDE.
> >>
> >>Anderson
> >>
> >>
> >>
> >
> >
> >
> >
>

C wrote:

>Hmm  where are you copying from to get this behavior ?  I copy from VS and
>it looks ok.  There is a way to convert automatically, just need something
>to test it with.
>
>  
>
Humm, VS must only do it sometimes.  BTW I use net VS.

Why not create a binary file in edit and then open with dide or copy from notepad.

> Hmm im not sure this is a bug.  Windows convention is to use \r\n as new line  , where unix is \n alone.  I can add a translate newline function ?

Well, AFAIK Mac convention is to use \r alone.

Now that Mac switched to Unix, is that still the case?

Sean

"Serge K" <skarebo@programmer.net> wrote in message news:btiosp$15up$1@digitaldaemon.com...
> > Hmm im not sure this is a bug.  Windows convention is to use \r\n as new line  , where unix is \n alone.  I can add a translate newline function
?
>
> Well, AFAIK Mac convention is to use \r alone.

> Now that Mac switched to Unix, is that still the case?

Apparently, not any more. (at least  for the new files:-)

http://en2.wikipedia.org/wiki/Newline
...
CR: Mac OS through 9
LF: Mac OS X

J Anderson wrote:

> Are there any plans to fix the bug where ASCII 10 by-itself (without 13) is not recognised as an enter?  Otherwise could charles put something in DIDE so ASCII 10 by themselves are fixed?  At the moment I'm resorting to copying into mozilla and pasting back into DIDE.  I suppose I could write a filter, but that wouldn't work with DIDE.
>
> Anderson
>
Another thing I'd like to point out, is that D supports /r for comments. It's not consistent.

ie

//a function
void func() {
}

That looks like:
line 1: "//a function\rvoid func(){\r\n}"

Compiles fine!

However, if \r isn't supported, then it shouldn't compile because it looks like this to the compiler
//a functionvoid func() {
} //Error should be here.

So I think the rule should be, whenever the compiler sees a \r or \n by itself it's a new line.  If  the compiler sees an \r pair \n (ie \r\n or \n\r), it's a new line (ie only count \n in this case) -> admitily this could be a small problem if you have something like:
\r\n\n\r\r -> 3 lines
Anyway most good editors handle this, so why not D?

> Anyway most good editors handle this, so why not D?

why not DIDE ?  I've updated it , im touching up the brace highlighting , and adding New File From template and will udpate later tonight.  Also mutlpile top level directories are now supported.

C
"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message
news:btko3c$13l0$1@digitaldaemon.com...
> J Anderson wrote:
>
> > Are there any plans to fix the bug where ASCII 10 by-itself (without 13) is not recognised as an enter?  Otherwise could charles put something in DIDE so ASCII 10 by themselves are fixed?  At the moment I'm resorting to copying into mozilla and pasting back into DIDE.  I suppose I could write a filter, but that wouldn't work with DIDE.
> >
> > Anderson
> >
> Another thing I'd like to point out, is that D supports /r for comments. It's not consistent.
>
> ie
>
> //a function
> void func() {
> }
>
> That looks like:
> line 1: "//a function\rvoid func(){\r\n}"
>
> Compiles fine!
>
> However, if \r isn't supported, then it shouldn't compile because it
> looks like this to the compiler
> //a functionvoid func() {
> } //Error should be here.
>
> So I think the rule should be, whenever the compiler sees a \r or \n by
> itself it's a new line.  If  the compiler sees an \r pair \n (ie \r\n or
> \n\r), it's a new line (ie only count \n in this case) -> admitily this
> could be a small problem if you have something like:
> \r\n\n\r\r -> 3 lines
> Anyway most good editors handle this, so why not D?
>