Edgewall Software

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

#Enhancedlists restructured and added new items

  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.

Wiki Markup 
||= header =||= another header =|| not a header ||
||= line xx=|| data1 || data2 ||
Display
header another header not a header
line xx data1 data2

Implemented in r9005

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

Wiki Markup 
||||= two headers =||= another header =||
|||| two cells || another cell ||
Display
two headers another header
two cells another cell

Implemented in r8698

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:

Wiki Markup 
|| 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 ||
Display
this is column 1 ​new ticket this is column 2 ​the road ahead that's column 3 and last one

Implemented in r8962

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.

Wiki Markup Display 
{{{#!td rowspan=2
A cell can now contain any markup:
 - lists
 - blocks
 - etc.
}}}
{{{#!td
Another cell with rich content,
on the same row
}}}
|-----------------------------------
{{{#!td
Another cell with rich content,
on the next row
}}}

A cell can now contain any markup:

  • lists
  • blocks
  • etc.

Another cell with rich content, on the same row

Another cell with rich content, on the next row

Implemented in r9064

In r9069, the #!tr wiki processor was added as well.

What is possibly missing now is a way to specify attributes to the table itself, so maybe a #!table wiki processor could be used for that (implemented in r9106) (also |+ MediaWiki style caption or #!caption?)

Enhanced lists

There are several enhancements that come to mind:

Wiki Markup Display 
- this is a list
- next item
  • this is a list
  • next item

Implemented in r9014

  • 1) style numbered items and o style numbered items (see also #5498)
Wiki Markup Display 
 o  this is a list
 o  that's another list

1) Point 1

2) Point 2

o this is a list o that's another list

1) Point 1

2) Point 2

Wiki Markup Display 
1. start a list

1. continue in the same list
  1. start a list
  1. continue in the same list
  • when continuing an item on the next line, one should stay within the item if we don't dedent past the item starter symbol (#4848)
  • support for WikiCreole-style lists (gains compatibility with e.g. MediaWiki)
Wiki Markup Display 
* start a list
** subitem
*** sub-subitem
# ordered list
## numbered subitem
  • start a list

subitem * sub-subitem # ordered list ## numbered subitem

Notes:

  • issue #6482 is at work here, as the tables are not part of their corresponding item
  • 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
...

Implemented in r9015.

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

This was implemented in r9066.

Allowing {{{ div ... would be easy, is it worth it? probably not, let's keep #!

Another changes in this area (r9065, r9068) allowed to indent the blocks yet have their content only contain relevant space.

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. This was implemented in #8204.

For div and tables, add some more "standard" classes (we already have "important" for divs and "listing" for tables):

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.