2.3 encoding parsing bug

[Edward K. Ream]

> OTOH, LEO _should_ not have come up with its own syntax to specify an
> encoding. Instead, LEO should have used established conventions, such
> as
>
>    -*- coding: <codingname> -*-

Leo came up with its own syntax because the $@+leo line is doing something
very different from most -*- coding lines.  Furthermore, Leo's file format
predated Python 2.3. It should have been reasonable to assume that a line
that starts with #@+leo would not ever be interpreted in any way by Python.

http://www.python.org/doc/2.3/whatsnew/section-encodings.html
completely misstates the truth and is actively misleading.  Sure, pep 263 is
strictly accurate, but I probably never looked at 263 before today.

Pep 263 does not discuss the issue that bites Leo: the more general the re
the more likely there is to be unintended consequences.  True, one doesn't
want to limit the matches that one _does_ want with encoding lines produced
by other editors.  So it's not clear exactly what re to choose.

For me, this discussion is moot.  The damage has been done, Leo's file
formats must change, and Leo 4.1 will not ever work as smoothly with Python
2.3 as I would like.

Edward
--------------------------------------------------------------------
Edward K. Ream   email:  edreamleo at charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------