Ben Wing wrote: [snip] 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? 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 same. 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 line endings. - 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) 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. Hope this helps, Cary