Edgewall Software
Modify

Ticket #9248 (new enhancement)

Opened 22 months ago

Last modified 12 months ago

Trac as reST editor

Reported by: anatoly techtonik <techtonik@…> Owned by:
Priority: normal Milestone: next-major-0.1X
Component: wiki system Version: 0.12dev
Severity: normal Keywords: docutils restructuredtext
Cc:
Release Notes:
API Changes:

Description

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.

Attachments

Change History

comment:1 Changed 22 months ago by anatoly techtonik <techtonik@…>

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

comment:2 Changed 22 months ago by anatoly techtonik <techtonik@…>

  • Component changed from rendering to wiki system

comment:3 follow-up: Changed 20 months ago by cboos

  • Keywords docutils restructuredtext added
  • Milestone set to next-major-0.1X

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.

comment:4 in reply to: ↑ 3 Changed 12 months ago by cboos

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.

View

Add a comment

Modify Ticket

Change Properties
<Author field>
Action
as new
as The resolution will be set. Next status will be 'closed'
to The owner will be changed from (none). Next status will be 'new'
The owner will be changed from (none) to anonymous. Next status will be 'assigned'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.