#5 Dos/Win Line Ending Format Broken


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?


  • Daniel Pozmanter

    Logged In: YES

    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.

  • Daniel Pozmanter

    • status: open --> wont-fix-invalid
  • Stephen Anderson

    • status: wont-fix-invalid --> pending
  • Stephen Anderson

    Logged In: YES

    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.


  • Stephen Anderson

    • status: pending --> open
  • Stephen Anderson

    Logged In: YES

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

  • Daniel Pozmanter

    Logged In: YES


    I'll look into it again.

  • Daniel Pozmanter

    • priority: 5 --> 7
  • Nobody/Anonymous

    Logged In: NO


    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.

  • Stephen Anderson

    Logged In: YES

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

  • Daniel Pozmanter

    Logged In: YES

    Good catch. Actually, there is also a bug that will give
    you the \r\r\r endings in drText.py.

    So you pointed out two bugs, and quashed one of them for me.

    I applied your fix, and also fixed the drText bug, then
    updated cvs.

    I am hoping to get 2.3.0 out soon.

    Thanks for not giving up on the bug, it would have been a
    nasty one to have creepin around.

  • Daniel Pozmanter

    • status: open --> closed-fixed

Log in to post a comment.