Version 8 (modified by 14 years ago) ( diff ) | ,
---|
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). This was implemented in #8204.
That will be needed by the !#th and !#td processors, in order to handle rowspan, colspan, and maybe alignment attributes.
TracLinks
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.
For pure CamelCase words, the MoinMoin style of using empty code spans ``
as a separator also works in Trac: CamelCases.
Alternative forms of linking
- <http://anything-(but-greater-than)>, see #7386
- Creole-style (MoinMoin supports it now)
[[<link>|blah blah]]
[=#anchor <label>]
creation, see #6413
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:
- GoogleCode uses http://code.google.com/p/support/wiki/WikiSyntax
- Mostly compatible markup, with the notable exception of
*...*
and_..._
used for bold and italics. This is not something we're going to support, considering all the complaints we already had with our underline style__...__
. - Internal Wiki links are a bit easier to write:
[Wikipage]
instead of["Wikipage"]
for us. - automatic heading anchors are more readable (
== Wiki-style markup ==
corresponds toWiki-style_markup
instead ofWiki-stylemarkup
)
- Mostly compatible markup, with the notable exception of
- BitBucket uses http://www.wikicreole.org/wiki/Creole1.0
- See WikiCreole.
- BitBucket has also a nice automatic preview of the Wiki text.
- RedMine uses http://www.redmine.org/help/wiki_syntax_detailed.html based on http://hobix.com/textile
- also uses
*...*
and_..._
used for bold and italics… - syntax for bulleted lists is similar to the WikiCreole one
- also uses
- others?