markdown support

[anonymous]

It'd be nice to see support for ​Markdown with ​SmartyPants support. Both are available as PHP libraries, so it shouldn't be difficult to include.

[Emmanuel Blot]

WikiRestructuredText is already available with Trac, which offers something similar to what ​Markdown seems to do.

Fancy formatting ​SmartyPants could be obtained with a customization of one of the already available plugins, such as ​EmoticonsPlugin or ​WikiGoodiesPlugin .

It is always possible to add such tools using the plugins architecture, but this cannot be part of the Trac core project. I really don't think it would be a good idea to add a PHP or PERL-written library to the Trac project which is itself written in Python ;-)

[anonymous]

It completely escaped me that Trac's written in Python, not PHP. My bad.

[anonymous]

Perhaps consider the ​python implementation of Markdown…

[anonymous]

Reopening this ticket, given the existence of a Python markdown module.

[anonymous]

Reopening this ticket, given the existence of a Python markdown module.

I love trac, but hate the wiki syntax - markdown support (well, and a proxy webdav view of the wiki) would make trac the ultimate über project and documentation tool from heaven.

See: ​http://www.trac-hacks.org/ticket/353#comment:4

Also, and note that markdown support is the #1 voted plugin request on trac-hacks.org - people (like me) badly want this: ​http://www.trac-hacks.org/wiki#VoteforaRequest-a-Hack

Smartypants would be pimp but not necessary.

[Emmanuel Blot]

Replying to anonymous:

Reopening this ticket, given the existence of a Python markdown module.

Also, and note that markdown support is the #1 voted plugin request on trac-hacks.org - people (like me) badly want this: ​http://www.trac-hacks.org/wiki#VoteforaRequest-a-Hack

Yes, this could be implemented as a plugin, so I would recommend to close this ticket as wontfix, as there are few chances that the wiki syntax changes at this point of the project, and Trac already supports two kinds of syntax.

[anonymous]

Well, but there's a difference between supporting markdown with a processing instruction, and supporting it properly _as_ wiki syntax.

I think the coolest plugin would simply have a look at the syntax and decide which wiki processor to use; the builtin trac processor or markdown, or something else better that someone thinks up in a year.

Wouldn't be hard, as there are definitive clues to use in each set of syntax. One could even provide an override in syntax or as a preference.

[Christian Boos]

Replying to anonymous:

Reopening this ticket, given the existence of a Python markdown module.

… which means that a WikiProcessor plugin could be written in order to support that.

I think the coolest plugin would simply have a look at the syntax and decide which wiki processor to use; the builtin trac processor or markdown, or something else better that someone thinks up in a year.

That's #615.

[anonymous]

i can't afford to learn 20 different syntax languages for 20 different systems. i've got my cms setup with markdown. if i'm going to use trac, i'm going to want to configure it with markdown. i've already learned / memorized most of the markdown syntax. i don't want to have to break down and learn yet another syntax.

given that there's already a python implementation of markdown, for a python developer, it should be trivial to plug in support for markdown in addition to whatever existing syntaxes trac already supports.

i hope you now understand the reasons why markdown support is important, and why giving users a choice in markup syntax is important. i have an installation of trac setup but for all practical puproses i don't use it; because i'm handicapped by the syntax and refuse to learn yet another wiki syntax. multiply that by the size of the markdown community.

[Christian Boos]

Please re-read comment:8. It is possible to write such a plugin, please do so or find someone to do it for you. We have already expressed that we're not interested in doing that as part of the core project.

[steverweber@…]

I understand that this was 'settled' 5 years ago. However markdown continued to progress and seems to have passes reStructuredText in overall user base ​http://stackoverflow.com/questions/34276/markdown-versus-restructuredtext

I feel that markdown should be revisited before the release of 13. Its just a simple 2.1kb file that would be included in the release… ​http://trac-hacks.org/wiki/MarkdownMacro

[andy@…]

+1 for inclusion of Markdown. Agreed that you can do the same things with Trac markup, but Markdown has an established presence on e.g. StackOverflow and GitHub, so it more "standard". And it is convenient to only have to know one markup language.

I think the StackOverflow Markdown dialect has been a bit customised — their formatting help page has some information about that, but IIRC it's mainly things like auto-linking text that looks like URLs, which Trac already does.

[sia@…]

Another vote for native support of Markdown in Trac.

[Christian Boos]

Me too!

(watch the MarkDown space)

[anonymous]

+1

[anonymous]

＋1

[planders@…]

I've got the ​th:MarkdownMacro plugin, and that's nice, but what I'd like in Trac is automatically rendering README.md when viewing a directory, a la Github. How feasible is that?

[Jun Omae]

Replying to planders@…:

I've got the ​th:MarkdownMacro plugin, and that's nice, but what I'd like in Trac is automatically rendering README.md when viewing a directory, a la Github. How feasible is that?

Please ask for support on Trac usage on the MailingList or IrcChannel. Also, see ​th:ReposReadMePlugin.

[anonymous]

As I'm preparing to move my development to git, and markdown seems to be a standard on git, I really want this support for README.md and maybe also markdown syntax in the wiki on the long run. Otherwise, I'll probably migrate to github, gitlab or the like, sorry. Also sorry for being this outspoken on alternatives. I like trac, and it has served me well. But I don't want to add yet another hack, its becoming unmaintainable…

[Ryan J Ollos]

For repository readme rendering support, see also #3098. It would be a good feature to implement.

It is useful to know what challenges are faced by end users. That being said, what we really need is more contributors (see ThisTicketWasOpenedTenYearsAgo).

[Ryan J Ollos]

Retargetting tickets to narrow focus for milestone:1.2. Please move the ticket back to milestone:next-dev-1.1.x if you intend to resolve it by milestone:1.2.

[anonymous]

Since 11 years… Will anyone actually look at this ticket ?

[Ryan J Ollos]

See ThisTicketWasOpenedTenYearsAgo.