ManpageRender for mimeview

[p.ohanlon@…]

I have implemented a UNIX style Man Page render for Trac - it uses groff (which commonly available on unix systems).

It recognises the appropriate mimetype (application/x-troff-man) and provides an HTML rendered version of the man page.

I have created a ticket with the Render attached: ​https://frostie.cs.ucl.ac.uk/nets/mmedia/ticket/173

It also installed and working my Trac system see: ​https://frostie.cs.ucl.ac.uk/nets/mmedia/browser/rat/trunk/man/man1/rat.1

Although it is implemented on 0.9.3 Trac system - the code would run unchanged on 0.10.

[p.ohanlon@…]

ManpageRender python code install to: /usr/lib/python2.4/site-packages/trac/mimeview

[Emmanuel Blot]

I think this is a good plugin candidate, as it uses an external tool and as man pages are platform-specific

[Christian Boos]

I think that this would be quite generally useful, at least as much as the php highlighter or the other stuff we have in mimeview. Now we can certainly handle that as a plugin, but I think a bundled plugin would be better.

[Emmanuel Blot]

Replying to cboos:

I think that this would be quite generally useful, at least as much as the php highlighter or the other stuff we have in mimeview. Now we can certainly handle that as a plugin, but I think a bundled plugin would be better.

Maybe part of the "official" plugin list yeah, but I don't think it is worth adding this feature in Trac core (and PHP support should follow the same path, IMHO)

[Christian Boos]

I think that's actually a quite good example the differentiator:

• Trac mimeview doesn't need any of the mimeview modules in core, besides api itself.
• Trac shipped without e.g. patch.py or pygment_renderer.py would be much less useful: it makes sense to bundle them (let's say 90% of the users will need those)

So the manpage renderer is maybe not as needed as the above (let's say, 60%), but it's definitely a plus to have it. Then we have php.py, silvercity.py and enscript.py, each perhaps useful to 10% of the users. Should we unbundle them? Stop supporting them? Perhaps. But the cost to maintain them together, somewhere close to the mimeview.api is surely less than having them distributed separately. In particular for this case, where the IHTMLPreviewRenderer interface is still highly likely to change.

So in order to make the distinction clear, we could move them to the tracext package (tracext.mimeview).

[Christian Boos]

Sorry, I've overestimated the % of users that are likely to use that manpage renderer - it's only about rendering troff source, which is likely not a very common situation.

What I had in mind when saying that "60% of users could be interested" was to have the Unix man page information available within Trac.

[Emmanuel Blot]

Replying to cboos:

Then we have php.py, silvercity.py and enscript.py, each perhaps useful to 10% of the users. Should we unbundle them?

I think that would be nice yeah, at least to avoid polluting the trac log with warning messages every time a Trac instance is spawned from Apache when Pygments is installed and Trac does not need at all these extensions.

Stop supporting them? Perhaps

Maybe not, but a "goodies" package/plugin would be great.

[Piers O'Hanlon]

FYI: have submitted this and my updated version for trac-0.11 to trac-hacks.org: ​https://trac-hacks.org/wiki/ManPageRendererPlugin

[Remy Blank]

Candidate for tracopt or close as "doneasaplugin"?

[Thijs Triemstra]

Replying to rblank:

Candidate for tracopt or close as "doneasaplugin"?

"doneasaplugin"?

[Remy Blank]

Yes, done-as-a-plugin :)

Fixing the resolution (fixed is for the case where something was actually done in Trac).