[Bug: 21.5] Confusion over line endings
ben at xemacs.org
Tue Dec 13 23:56:25 EST 2005
Cary Jamison wrote:
>Ben Wing wrote:
>>Cary Jamison wrote:
>>>Dear Bug Team!
>>>Since installing this latest Beta, I have noticed a problem with line
>>>endings that I have not seen in previous Windows versions of Xemacs.
>>>I have been able to narrow it down to a simple example.
>>>Load a file with DOS line endings. Make a small change to it
>>>it. If you look at the file in another editor, you will see that it
>>>now has UNIX line endings. This is the first problem that did not
>>>exist previously and probably leads to the others - Xemacs would
>>>preserve whatever line endings the file originally had.
>>>In the other editor or tool, convert the file back to DOS
>>>In Xemacs, reload the file. It will now appear with a '^M'
>>>at the end of each line. To clear these off, you can kill the buffer
>>>and reload the file.
>>>I first noticed this happening using the Perforce scc plugin. Doing
>>>things such as reverting a file would cause the '^M's to appear. I
>>>then narrowed it down to how Xemacs is inappropriately converting the
>>>line endings and then assuming that format if the file gets reloaded.
>>there's a bug in revert-buffer in its handling of line
>>endings. i've seen this too but haven't had a chance to track it down.
>Thanks for your response, Ben.
>They way I was 'reloading' the file, as I described it was using C-xC-f
>(find-file). If the file has changed it prompts if I want to re-read
>from disk. So, does this call the revert-buffer function in this case,
>or are there some other problems as well?
yes, this calls revert-buffer.
>Also, this doesn't explain why the file is getting saved with the wrong
>line endings to start with. I think the problem is before
>revert-buffer, that Xemacs has tagged the buffer with the wrong mode,
>and revert-buffer is then reloading in the wrong mode.
>I found a similar bug, [Bug: 21.5-b22] Cygwin XEmacs forces line-ending
>conversion, before sending in mine. I thought at first they were
>different, but after playing around a bit more, I think they are the
>You asked him if the buffer was marked with a :T on the modeline, but
>never got a response (at least there isn't one in the list archive). I
>hadn't noticed this marker before, but I see it exists in my old version
>of Xemacs as well.
>When I reproduce his problem, this is what I get :
>- create a new file, it is marked with MSW-MB:T and gets saved with DOS
>- revert-buffer, the file is still :T and doesn't change
>- kill the buffer and reopen the file, it is now MSW-MB (no :T)!
>Or, after the first step :
>- externall modify the file
>- revert-buffer, the :T goes away (but no ^Ms)
>>From this point it is the same as my bug. When I open an existing file,
>it is not getting the :T. I then save it and it gets Unix line endings.
>If I externally change the file and then execute revert-buffer I get the
>^Ms on the end of each line, and there is still no :T in the modeline.
>So, basically, the problem seems to be both opening an existing file or
>reverting a file that has changed the file is not recognized as DOS text
>(:T). I only see the :T on a new file or on other internal buffers,
>such as scratch, shell, dired, help, etc. However, the file is
>initially loaded correctly, but once marked without the :T a revert will
>cause the ^Ms to appear.
i remember that bug; i couldn't duplicate.
are you using cygwin? that's what the bug was under and that's what i
used to try and duplicate. the only thing i can think of is something
related to file systems mounted as text mode under cygwin. if you can,
try on different file systems, one mounted as text, the other binary,
and see if you can duplicate.
also, are you saying that the file definitely has CRLF's (use `od -bc'
to verify), but XEmacs loads it up without a :T in the modeline and
without visible ^M's? that would be strange; i've never seen it.
More information about the XEmacs-Beta