Re: [Zope-dev] Future of StructuredText
Richard Jones wrote: One of the big issues is that rest isn't optimised. I don't know what the scope is for optimising rest, nor have I got any real benchmark numbers. The emphasis so far has been to build it to spec. It's potentially much slower than stx because the latter has been around for longer and therefore is potentially more tweaked. The ReStructuredText Document works because I compile the source text into HTML when it's written. Nice and fast, and works well in content management environments. In the above DTML tag usage though, you'd want content to be quite small or the performance hit could be large. Well I have seen the alternative... and it isn't nice! The users happily paste in 300KB of obscure html from word. Html that is about 15 KB when run through Tidy that is! Besides, most of the stx documents I see my users paste in in real life is a few KB worth of text. Max... And the advantage is that REST has a syntax that is much closer to what ordinary users expect. In userland indentation is actually a hard problem. regards Max M Skeptic Effect or the Randi Effect When a skeptic is near, supernatural effects seem to disappear. evolve ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Future of StructuredText
On Thursday 05 September 2002 03:45 am, Max M wrote: [snip] In userland indentation is actually a hard problem. regards Max M http://lists.zope.org/mailman/listinfo/zope ) Indeed, most normal humans have trouble with understanding nested hierarchies. Something which we geeks often cannot understand since we surround ourselves with them. -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Future of StructuredText
Richard Jones wrote: [courtesy cc send to David G, so if I make any blatantly errneous statements he can come chase me with the Big Stick :)] Thanks for being a vocal proponent! On Wed, 4 Sep 2002 8:01 pm, Max M wrote: Andreas Jung wrote: I would be fine to have reStructuredText inside the Zope core (for 2.7) and to deprecate the current StructuredText in the long run. +1 +1 but with the reservations below :) ... One of the big issues is that rest isn't optimised. This is true. Optimization isn't even on the radar at this point, although I'd be more than happy if someone were to take a look at it. The emphasis so far has been to build it to spec. True. That's why there *is* a spec, and why the spec preceded the implementation. Even after the implementation of the initial feature set, whenever new features were added the spec was always updated first. One of my biggest problems with ST was its spec, or lack thereof. It's potentially much slower than stx because the latter has been around for longer and therefore is potentially more tweaked. I'd say ST (classic, anyhow; never grokked the NG code) is faster simply because it does much less. ;-) I believe migration may be possible - that is, the parser half of rest might be mutable enough to make it handle stx blocks and other syntax eccentricities. That's a question for David Goodger to answer really. Compatibility with ST was never a consideration; I took the good ideas and left the rest. Except for section structure, reStructuredText is mostly a superset of ST, but there may be some gotchas. The reStructuredText parser is built generically enough that it could (with recoding) handle ST as well. I don't see the need though. As I understand it though, there's ambiguities in stx that the rest parser might not interpret in the same manner as the stx parser. There's ST's use of 'o' as bullet list marker, for one. Footnotes footnote references are different, as are hyperlinks in general. There are others I'm sure. -- David Goodger [EMAIL PROTECTED] Open-source projects: - Python Docutils: http://docutils.sourceforge.net/ (includes reStructuredText: http://docutils.sf.net/rst.html) - The Go Tools Project: http://gotools.sourceforge.net/ ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Future of StructuredText
- Original Message - From: David Goodger [EMAIL PROTECTED] To: Richard Jones [EMAIL PROTECTED]; Max M [EMAIL PROTECTED]; Andreas Jung [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, September 05, 2002 06:35 Subject: Re: [Zope-dev] Future of StructuredText It's potentially much slower than stx because the latter has been around for longer and therefore is potentially more tweaked. I'd say ST (classic, anyhow; never grokked the NG code) is faster simply because it does much less. ;-) In deed - on the other side you could work with caches. Either on the restructuredText side to keep the cooked HTML, or you as RAM manager on the Zope level or Apache/Squid before the Zope instance. -aj ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Future of StructuredText
Andreas Jung wrote: I would be fine to have reStructuredText inside the Zope core (for 2.7) and to deprecate the current StructuredText in the long run. +1 Open points: how to migrate exisiting STX documents to reStructuredText Wouldn't the simplest solution be: dtml-var content format=rest ??? Then we could use both interchangably. regards Max M Skeptic Effect or the Randi Effect When a skeptic is near, supernatural effects seem to disappear. evolve ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Future of StructuredText
[courtesy cc send to David G, so if I make any blatantly errneous statements he can come chase me with the Big Stick :)] On Wed, 4 Sep 2002 8:01 pm, Max M wrote: Andreas Jung wrote: I would be fine to have reStructuredText inside the Zope core (for 2.7) and to deprecate the current StructuredText in the long run. +1 +1 but with the reservations below :) Open points: how to migrate exisiting STX documents to reStructuredText Wouldn't the simplest solution be: dtml-var content format=rest ??? Then we could use both interchangably. One of the big issues is that rest isn't optimised. I don't know what the scope is for optimising rest, nor have I got any real benchmark numbers. The emphasis so far has been to build it to spec. It's potentially much slower than stx because the latter has been around for longer and therefore is potentially more tweaked. The ReStructuredText Document works because I compile the source text into HTML when it's written. Nice and fast, and works well in content management environments. In the above DTML tag usage though, you'd want content to be quite small or the performance hit could be large. I believe migration may be possible - that is, the parser half of rest might be mutable enough to make it handle stx blocks and other syntax eccentricities. That's a question for David Goodger to answer really. As I understand it though, there's ambiguities in stx that the rest parser might not interpret in the same manner as the stx parser. The docutils/rest project has an analysis of the stx format: http://docutils.sourceforge.net/spec/rst/problems.html Richard ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
