Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#5 Dos/Win Line Ending Format Broken

closed-fixed
nobody
None
7
2004-02-29
2004-02-28
Stephen Anderson
No

I am running under WinXP. I have had my line ending format set to Dos/Win for a while. I created a new le.py and typed in:
This is a test.

This is only a test.

When I pulled it into UltraEdit, UE asked me if I wanted to convert to DOS mode. I said no. I then entered hex edit mode. To my surprise, hex edit mode revealed:
This is a test.\0x2E\0x0D\0x0DThis is only a test.\0x2E\0x0D\0x0D\0x0D

Son lines with text and carriage return get \r\n and blank lines get only \n?

Discussion

1 2 > >> (Page 1 of 2)
  • Logged In: YES
    user_id=796750

    This does not seem to be a problem with DrPython.

    When I create files with drpy, it uses the line ending style
    I want
    it to, whether that is mac, win, or unix.

    In any case, drpy now identifies mixed mode files, and warns
    on open.

    If you paste in code that includes unix line endings to a file
    that has windows line endings, the file will become mixed.
    DrPython does not currently detect this kind of event.

     
    • status: open --> wont-fix-invalid
     
    • status: wont-fix-invalid --> pending
     
  • Logged In: YES
    user_id=53053

    Umm.... can you check again?

    Please read my description again. I re-ran my test creating a new file with DrPython. On the off chance that UltraEdit was responsible, I used a different hex editor to check the new file. The new file most definately has the same \r\n\n\n anomaly. If this is not DrPython, I'll send you for the trouble.

    I have my prefs set to Dos/Win and check line endings is checked.

    I am not pasting, just typing.

    Thanks.

     
    • status: pending --> open
     
  • Logged In: YES
    user_id=53053

    That was supposed to read, "If it's not DrPython, I'll send you fifty bucks for the trouble."

     
  • Logged In: YES
    user_id=796750

    LOL.

    I'll look into it again.

     
    • priority: 5 --> 7
     
  • Logged In: NO

    Daniel,

    My follow-up was off. \0x2E\0x0D\0x0D\0x0D is not \r\n\n\n it's .\r\r\r

    I did some digging into the DrPython code. The prefsDialog code sets the eolmode to one of 0:\n, 1:\r\n: 2\r BUT, drpython.py, drPrompt.py, and drText.py all have a different ordering. They use 0:\n 1:\r 2:\r\n

    This corresponds to the fact that I'm trying to use option 1 (DOS/Win) in the prefsDialog and am seeing only \r's.

    The fact that I had a file with mixed mode is almost undoubtedly due to setting the mode in the dialog box and doing some editing then later closing and reopening and doing editing. Although I haven't tracked the code down, I'm guessing when I set the mode in the dialog box, the correct mode get's used for that session. Then, when the prefs are reloaded from the file, it gets the messed up mapping and starts only using \r.

     
  • Logged In: YES
    user_id=53053

    Based on my last discovery, I started patching my copy to get the orderings the same. Curiously, I found the place in drpython.py that detects the mode uses the mapping from the prefsDialog but not the mixed-up mapping from the drfText, and drPrompt.

    That led me to another find. Starting on line 2227 (from v2.2.7) of drpython.py, there is this code:

    if (self.prefs.eolmode):
    emode = wxSTC_EOL_CRLF
    elif (self.prefs.eolmode == 2):
    emode = wxSTC_EOL_CR
    else:
    emode = wxSTC_EOL_LF

    Shouldn't that first line be:
    if (self.prefs.eolmode == 1):

    If not, when will the second condition every be true but not the first?

     
1 2 > >> (Page 1 of 2)