Am 11.05.2007 um 01:09 schrieb Alexander Limi:
On Thu, 10 May 2007 07:28:49 -0700, Charlie Clark
<[EMAIL PROTECTED]> wrote:
Anyway before I submit a follow-up to the bug is there any CMF
setting I can use to avoid this problem?
It's a known issue with STX.
Thanks, does that mean anything's being done about it? I would have
thought Plone users would be suffering the most with it.
I spent some time looking at the underlying code yesterday and can
see what's causing the problem. If I take my own medicine the STX
code should be fixed.
STLetters simply makes use of string.letters and string.digits which
are then thrown into various re's
expr = re.compile(r'\*\*([%s%s%s\s]+?)\*\*' % (letters, digits,
This will work with non-ascii only if the encoding for string.letters
and the text to be compared is the same which, certainly on my
machine is not the case, but can be easily fixed.
letters = string.letters.decode(locale.getlocale().encode
I thought that the default_zpublisher_encoding would do but that's
wrong. Assuming it's possible to get the value from Zope surely this
would be a relatively painless fix?
It might be an idea would be to hook into the ReST encoding
directives that are mysteriously included in /etc/zope.conf
An alternative would be to coerce the use of unicode and simply
compare against that:
re.compile(r'\*\*([\s\w]+?)\*\*', re.U) #extended as necessary for
The advantage of this is that it would be entirely independent of
locale but this would take more work on STX which seems to choke if
Going back briefly to ReST: if Zope seems ready to support this out
of the box, wouldn't it useful to support ReST in
CMFDefault.Document? Or is the dependency on docutils too precarious?
It could be added gracefully to the edit form if import
reStructuredText succeeded. Or is this yet another case of me being
behind the loop again?
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests