EOL created by .write or .encode

[Alan Mackenzie]

In comp.emacs.xemacs Xah Lee <xah at xahlee.org> wrote:
> I found the problem now. (after some  one hour debug time) Python
> didn't have problem. Emacs does.

> If you open a file in emacs, it will open fine regardless whether the
> EOL is ascii 10 or 13. (unix or mac) This is a nice feature. However,
> the what-cursor-position which is used to show cursor position and the
> char's ascii code, says the EOL is ascii 10 when it is in fact ascii
> 13.

The problem is that there are many ways (at least 3) of indicating where
one line of text ends and the next one begins.  Emacs deals with this
problem by converting the file loaded from disk to an internal format,
and converting back again when the time comes to save it again.  The
alternatives would have been worse: noting the line-end convention of
each file, and complicating many routines (and we're talking about more
than "at least 3") to take account of that.

The internal representation of an EOL is 0x0a.  Now that you know this,
it shouldn't bother you again.  Alternatively, you could write a patch
for `what-cursor-position' to fix the problem (if such it be) and submit
it to the mailing list (xemacs-beta at xemacs.org, or something like that).
However, it might introduce more problems than it would solve.  I suspect
the developers would reject it.

> Fuck the irresponsible fuckhead who is responsible for this.

You having a bad day, or something?  ;-)  The fuckhead was probably RMS
(Richard Stallman, he of the Free Software Foundation), and he's been
fucked so many times that once more wouldn't achieve anything at all.
;-)

-- 
Alan Mackenzie (Munich, Germany)
Email: aacm at muuc.dee; to decode, wherever there is a repeated letter
(like "aa"), remove half of them (leaving, say, "a").