@shadow - @encoding windows-1250 - problem

26 views
Skip to first unread message

zensign

unread,
Jun 28, 2011, 4:36:14 AM6/28/11
to leo-editor
@file and @nosent works Ok, but @shadow don't.

Content of the node:
šđčćž
ŠĐČĆŽ

@file:

#@+leo-ver=5-thin-encoding=windows-1250,.
#@+node:tvlainic.20110628074802.1297: * @file C:\test\te.prg
#@@encoding windows-1250
šđčćž
ŠĐČĆŽ
#@-leo


@nosent:

šđčćž
ŠĐČĆŽ

@shadow:

??
???

#--unknown-language--@+leo-ver=4-thin-encoding=windows-1250,.
#--unknown-language--@+node:tvlainic.20110628074802.1299:@shadow C:
\test\tes.prg
#--unknown-language--@@encoding windows-1250
??
???
#--unknown-language--@-node:tvlainic.20110628074802.1299:@shadow C:
\test\tes.prg
#--unknown-language--@-leo

wgw

unread,
Jul 1, 2011, 6:46:16 PM7/1/11
to leo-e...@googlegroups.com
I'm guessing we are both encountering the same problem: https://groups.google.com/d/topic/leo-editor/vBOK1_Z49mg/discussion

zensign

unread,
Jul 6, 2011, 4:14:02 AM7/6/11
to leo-editor
@file and @nosent work Ok.
Problem is in @shadow !

Edward K. Ream

unread,
Oct 21, 2011, 6:39:14 PM10/21/11
to leo-e...@googlegroups.com
On Wed, Jul 6, 2011 at 3:14 AM, zensign <tvla...@gmail.com> wrote:
> @file and @nosent work  Ok.
> Problem is in @shadow !

My profuse apologies for the delay in responding.

Rev 4636 of the trunk fixes several unicode related problems.

However, before going into details about the fixes, let me emphasize
that when you use non-default encodings, you *must* use @encoding
directives or Python's -*- coding lines to specify the proper encoding
to use in a file.

I should have said this months ago: using @encoding would have been
the workaround, and it is *still* what you must do.

Having said that, here is the checkin log:

Fixed several encoding problems related to this thread: @shadow -
@encoding windows-1250 - problem
http://groups.google.com/group/leo-editor/browse_thread/thread/a4ba80559447218a/9a37a4ed6c44d452

There were several real problems fixed. The summary: @encoding
directives were always required and are *still* required for unusual
(non-default) encodings *unless* a Python -*- coding line is the very
first line of the file.

In detail:

1. at.initWriteIvars now checks for a Python # -*- coding: line.
If present, it must be the very first line.
If present, it will override any @encoding directives.

2. g.getPythonEncodingFromString now can deal with either of the
following lines:

@first # -*- coding: utf-8 -*-
# -*- coding: utf-8 -*-

That is, g.getPythonEncodingFromString can strip the leading @first.

3. g.readlineForceUnixNewline and x.propagate_changes now catch
UnicodeDecodeError. This is very important: previously decoding errors
crashed Leo!.

4. x.propagate_change now does the preread in 'rb' mode. This seems to
be essential.

All unit tests pass with both Python 2.x and 3.x.

Edward

wgw

unread,
Oct 22, 2011, 2:25:31 PM10/22/11
to leo-e...@googlegroups.com
Thanks for the upgrade! These encoding issues have always been a plague (much like the slash/backslash plague.)

Edward K. Ream

unread,
Oct 22, 2011, 4:56:24 PM10/22/11
to leo-e...@googlegroups.com
On Sat, Oct 22, 2011 at 1:25 PM, wgw <wgwi...@gmail.com> wrote:
> Thanks for the upgrade! These encoding issues have always been a plague
> (much like the slash/backslash plague.)

You're welcome.

Edward

Reply all
Reply to author
Forward
0 new messages