Edgewall Software

Version 7 (modified by Christian Boos, 14 years ago) ( diff )

Justify the reason to add new style anchors

  1. Topics
    1. Simple Tables
    2. Enhanced lists
    3. Enhanced headings
    4. Enhanced processors
    5. TracLinks
  2. Compatibility with other Wiki Markups

Trac Wiki Syntax enhancements

Topics

Simple Tables

Simple tables in Trac are really too primitive. Some simple enhancements that would greatly enhance their expressiveness could be made.

support for <th>

This is #3347.

The syntax would be: 

||= header =||= another header =|| not a header ||
||= line xx=|| data1 || data2 ||

support for column span

I have a patch, but #1293 suggests that the preferred syntax would be to have an even number of pipes, e.g. |||| and |||||| to indicate a span of 2 and 3, instead of ||| and ||||.

long columns

Then, simple tables are not that readable when there are multiple cells with long content. It would be better to be able to have one cell per line, without triggering the creation of a new row. The \ continuation character come to mind: 

|| this is column 1 [http://trac.edgewall.org/newticket new ticket] || \
|| this is column 2 [http://trac.edgewall.org/roadmap the road ahead] || \
|| that's column 3 and last one ||

even longer columns

Now for complex content, it would be extra-cool to be able to embed any wiki content in a cell. That can be achieved at little cost, as usual by using processing instructions. We'd need to add !#th and #!td, and find a way to trigger the creation of new rows. Besides rich content, this also offers an alternative syntax for #supportforth and for #supportforcolumnspan, as well as giving the possibility to specify the rowspan.

Enhanced lists

There are 3 enhancements that come to mind:

  • no leading spaces (#124); I just realized that RestructuredText also doesn't require a leading space, neither does WikiCreole
  • 1) style numbered items and o style numbered items (see also #5498)
  • support empty lines between items (#1936, #6482)

i.e. 

- this is a list
- next item

 o  this is a list
 o  that's another list

1) Point 1

2) Point 2

In the above points 1) and 2) should be part of the same list.

Implementation note: slight difficulty for the VerticalHorizontalParsing, need to consider empty lines as potential "no-ops" in some situations.

Enhanced headings

The automatic ids generated for headings are not readable. We should replace spaces by hyphens, at the very least. Compatibility with the old compact style could be achieved by using the name attribute, whereas id would be used for the new, more readable style. This is especially important for languages when titles use sentence-style capitalization, not title-style capitalization (see e.g. ​Section_headings in Wikipedia).

In the line of Trac:WikiCreole support, we should not require closing =*.... Starting with an = sign should be enough. This would match ​RDoc rule 4. as well.

Example: 

= Main Title
== Section 1
...

Enhanced processors

We could do with a more compact syntax for WikiProcessors. The #! stuff doesn't need to be on a standalone line, it should be possible to stuff it on the same line as the {{{ prefix. e.g. {{{#!div ... maybe even {{{ div ... if possible (probably not).

Also, not only the div but any other processor should be able to get extra properties (key=value pairs, like for divs).

That will be needed by the !#th and !#td processors, in order to handle rowspan, colspan, and maybe alignment attributes.

CamelCase

The MoinMoin style internal free link has been introduced to cope with wiki words with appended content, like when writing ["WikiProcessor"]s. First, the implementation is restricted: it doesn't allow for a lhref equivalent, ["WikiProcessor" the wiki processors] (#7695). What if we would instead re-use the lhref regexp, in the quoted case? It would be equivalent to making the wiki: prefix the default namespace. The advantage would be that any word could be wikified that way.

  • ["checking"] → checking: works already
  • ["checking" the check] → the check: doesn't work

For pure CamelCase words, the MoinMoin style of using empty code spans `` as a separator also works in Trac: CamelCases.

Alternative forms of linking

Compatibility with other Wiki Markups

While achieving universality is likely not possible, there are both many interesting ideas that could be grabbed from other Wiki markups and incompatibilities than could be eased out.

Here are several other markups that are very interesting for us as they also target similar kinds of users that we do:

Note: See TracWiki for help on using the wiki.