Re: modeline indicator: line ending DOS, Linux, Mac
On 1/12/2013 6:28 PM, Stephen J. Turnbull wrote:
steven Mitchell writes:
> Posted inline, since I am not sure if we can post attachments.
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.
Thanks for making that clear.
> Hopefully someone who knows more about different encodings
> can suggest improvements.
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.
I realize that
Uwe was asking about an indicator of current file line
end encoding.
That would be really good and I want to add that functionality, but not
on the
modeline for me.
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.
Interesting, I hadn't realized
that. Do you know which modes I should
be careful of?
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.
Yes, the fanuc line ends are a special case, found nowhere else but
older fanuc controls
They are hard coded into an industrial controller with very few
parameters that can change
how files are output. Notice I did not put in a reverse change of line
ends into that format, as
they will receive straight up LF line ends, just won't output that way.
With a Citizen Swiss lathe, a file that has CR+LF will upload OK but
will not be recognized as a valid program
until the line ends are LF only. I suppose that can be done with a
separate command line utility,
But what I need to happen is that the file is changed, not how it is
displayed in XEmacs.
I need it to upload a certain way. You can say that my use is an edge case,
or a very small part of how this would be used, and you might be right,
but it exists here and changing the file itself is what I want to have
happen.
I usually make further changes to the file as well, tool numbers, tool
positions, etc,
and it is saved in the line-end encoding that is common to all
my machines, and not changed back to the original format.
If I can figure out how to tell the current line end encoding system,
I'm still intending to add that information
to the sub-menu title.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta