EOL created by .write or .encode

[Xah Lee]

Why is that some of my files written out by
outF.write(outtext.encode('utf-8'))
has ascii 10 as EOL, while others has ascii 13 as EOL?
both of these files's EOL are originally all ascii 10.

If i remove the EOL after the tt below in the place string, then this
doesn't happen.

findreplace = [
(ur'</body>',
ur'''tt
</body>'''),
]

....

inF = open(filePath,'rb')
s=unicode(inF.read(),'utf-8')
inF.close()

for couple in findreplace:
outtext=s.replace(couple[0],couple[1])
s=outtext
outF = open(tempName,'wb')
outF.write(outtext.encode('utf-8'))
outF.close()

thanks.

Xah
xa*@xahlee.org
∑ http://xahlee.org/PageTwo_dir/more.html ☄

[Fredrik Lundh]

"Xah Lee" <xa*@xahlee.org> wrote:

Why is that some of my files written out by
outF.write(outtext.encode('utf-8'))
has ascii 10 as EOL, while others has ascii 13 as EOL? outF = open(tempName,'wb')
outF.write(outtext.encode('utf-8'))
outF.close()

UTF-8 is not a binary format. get rid of the "b" flags, and things
will work as expected.

</F>

[Xah Lee]

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. Fuck the irresponsible fuckhead who is responsible for this.

http://xahlee.org/UnixResource_dir/w...e_license.html

Xah
xa*@xahlee.org
∑ http://xahlee.org/

Xah Lee wrote:

Why is that some of my files written out by
outF.write(outtext.encode('utf-8'))
has ascii 10 as EOL, while others has ascii 13 as EOL?
both of these files's EOL are originally all ascii 10.

If i remove the EOL after the tt below in the place string, then this
doesn't happen.

findreplace = [
(ur'</body>',
ur'''tt
</body>'''),
]

...

inF = open(filePath,'rb')
s=unicode(inF.read(),'utf-8')
inF.close()

for couple in findreplace:
outtext=s.replace(couple[0],couple[1])
s=outtext
outF = open(tempName,'wb')
outF.write(outtext.encode('utf-8'))
outF.close()

thanks.

Xah
xa*@xahlee.org
∑ http://xahlee.org/PageTwo_dir/more.html ☄

[Aidan Kehoe]

Ar an naoiú lá de mÃ* Aibréan, scrÃ*obh Xah Lee:

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.

This _is_ the right thing to do--there’s no reason naive programs written in
Emacs Lisp should have to worry about different on-disk representations of
line-endings. If you want to open a file which uses \015 as its line
endings, and have those \015 characters appear in the buffer, open it using
a coding system ending in -unix. C-u C-x C-f /path/to/file RET
iso-8859-1-unix RET in XEmacs, something I don’t know but I’m certain exists
in GNU Emacs.

--
“I, for instance, am gung-ho about open source because my family is being
held hostage in Rob Malda’s basement. But who fact-checks me, or Enderle,
when we say something in public? No-one!� -- Danny O’Brien

[Xah Lee]

can any GNU person or emacs coder answer this?

specifically: why does what-cursor-position give incorrect answer.

Xah
xa*@xahlee.org
∑ http://xahlee.org/PageTwo_dir/more.html ☄

Xah Lee 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. Fuck the irresponsible fuckhead who is responsible for this.

http://xahlee.org/UnixResource_dir/w...e_license.html

Xah
xa*@xahlee.org
∑ http://xahlee.org/

Xah Lee wrote:

Why is that some of my files written out by
outF.write(outtext.encode('utf-8'))
has ascii 10 as EOL, while others has ascii 13 as EOL?
both of these files's EOL are originally all ascii 10.

If i remove the EOL after the tt below in the place string, then this doesn't happen.

findreplace = [
(ur'</body>',
ur'''tt
</body>'''),
]

...

inF = open(filePath,'rb')
s=unicode(inF.read(),'utf-8')
inF.close()

for couple in findreplace:
outtext=s.replace(couple[0],couple[1])
s=outtext
outF = open(tempName,'wb')
outF.write(outtext.encode('utf-8'))
outF.close()

thanks.

Xah
xa*@xahlee.org
∑ http://xahlee.org/PageTwo_dir/more.html ☄

[Alan Mackenzie]

In comp.emacs.xemacs Xah Lee <xa*@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 (xe*********@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: aa**@muuc.dee; to decode, wherever there is a repeated letter
(like "aa"), remove half of them (leaving, say, "a").