Re: modeline indicator: line ending DOS, Linux, Mac

steven Mitchell writes: You can post attachments up to a reasonable size which rules out most Word files but is sufficient for most Emacs Lisp libraries. Allowed MIME content types are text/*, image/*, multipart/*, message/rfc822, and application/octet-stream. IIRC application/pdf is allowed, but in general application/* is stripped (you can get it from the archives, though). In particular, you can use text/emacs-lisp but not application/emacs-lisp. Improvements, I'm not sure, but here are some observations: Your code doesn't address Uwe's issue, because it actually changes the contents of the buffer. This means that in the case of Unix->other, the buffer display will change unpleasantly. In the case of other->Unix, the display will improve, but if you don't change the EOL convention in the coding system, you may get a surprise on saving. This transformation has the potential to screw up some modes. It is a convention in those modes to use a bare CR as a placeholder for a newline following an "invisible" line. In general, it's not clear to me that this is a very useful feature for interactive use for these reasons. I would think that for naive users, a utility for translating *files* instead of buffers would be safer. However, given that (unless conventions are mixed) XEmacs should display the file correctly, it seems generally preferable to edit files in their "native" form. In particular, in a VCS-controlled environment, you will thrash the VCS (every time you change the on-disk EOL convention, all lines in the file will be changed making diff useless). The Unicode standard specifies that several forms of newline should all be considered equivalent in text files, and *interpreted* (ie, displayed) as a newline: CR, LF, CRLF, and LINE SEPARATOR (U+2028). This could be implemented as a regexp match, and you could simplify the menu to "to". (Python calls this "universal newlines". Universal newlines would misinterpret your FANUC line separators. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta