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.

My two cents - there are some things in rST I would like to have but I think it has gone too far with it's rules. If I had to choose one or the other right now I would stick with stxNG for simplicity and because it doesn't dictate things unnecessarily. I think the number one problem with stx for most people is the indenting hassle. These markups are evolving and I don't think we've seen the best designs yet. http://repose.cx/emacs/wiki/wikimarkup.pt is another which feels good to me, check it out. -Simon

On 9/4/02 10:59 AM, "Chris McDonough" <chrism@zope.com> wrote:

IMHO, the indenting hassle is one of the best features of "classic" STX. It's a pain to line things up but it does make for very readable source documents. I think STX-NG is a little better than ReST for constructing readable source docs; especially if they are long, like chapters of a book due to this indenting.

When writing books, however, you're most likely using an editor that makes it easy to reformat blocks at the proper indentation level. For a lot of web input where you still want to allow some simple structure, indentation is a pain in the ass. I do it because I'm used to it, but a lot of people just will type in a paragraph as a single line. Most of the time, this is fine in Structured Text, until they indent one of the paragraphs even by one space, turning the parent paragraph into a header block. The indentation in STX is especially annoying when trying to drop in example code, most likely pasted in from another source, and having to then move every line to the right level - thus, code that was formatted to fit well in eighty columns can be tricky to fit into an eighty column source STX document if it's a few sublevels in. I still have to find the right level, mix of colons and spacing, etc..., after all these years. -- Jeffrey P Shell www.cuemedia.com

"R. David Murray" <bitz@bitdance.com> writes:

it would be really sad. So if that is a ruling criterion, I'd vote for two versions of structured text, preferably with a translator between them.

Well, it would be easy enough (or maybe not, with current stx code) for structured text to accept either indentation or rST-style underlining to indicate headers. I wonder if it's possible to design a system that doesn't require indentation at all, but allows it as an alternate mechanism - without causing more confusion.

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 <goodger@users.sourceforge.net> 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/

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> > >