Trac as reST editor

[anatoly techtonik <techtonik@…>]

Trac markup is nice, but it is not suitable for documentation that should be distributed in various formats. For example, for Bitten reST is a better option as it could transformed by Sphinx into various stuff.

It could be nice if Trac could maintain documentation in specially designated wiki namespace as reST docs, so that these docs can be then synced back with version control system.

If it is possible to create a 1:1 symmetrical Trac to reST markup mapper (Genshi?), even partial - Trac could be used as online editor for Bitten docs, which will surely improve community participation.

[anatoly techtonik <techtonik@…>]

reST pages may bear a special "type" in DB if there is such "type" field.

[Christian Boos]

The whole content of a wiki page could actually be considered as a processor block. We could interpret the first line as a block directive, so if the page starts with #!rst, the whole content is going to be reST.

Another thing which is quite annoying when editing / displaying reST in Trac are the obnoxious error messages when using markup directives not understood by docutils, or simple layout errors. We should really show something less intrusive.

[Christian Boos]

Replying to self:

Another thing which is quite annoying when editing / displaying reST in Trac are the obnoxious error messages when using markup directives not understood by docutils, or simple layout errors. We should really show something less intrusive.

That was done in [10358].

---

Giving another thought at this, I think there are two approaches, not necessarily incompatible:

1. effectively use namespaces and specify a default "format" for the pages
2. use a dedicated repository for the documentation and #3519

Not necessarily incompatible, as both ways would eventually work. With #1132, the edits done in Wiki pages a namespace could also end up in a repository. In the first case however, the structure of the repository would simply follow the structure of the wiki page hierarchy, while in the second solution, the structure of the repository could be arbitrary.