Show line numbers when embedding source code in wiki pages

[erik@…]

Hi

When embedding sourcecode in wiki pages using the {{{-Makro, I would sometimes like to have line numbers displayed. This would make it possible to reference some lines in a text, like:

We got some c-sourcecode here, in line 1, a buffer is allocated, in line 35, some data is copied to the buffer without checking the size of the data…

The svn browser shows line numbers, so I hope this will not be so difficult.

[sid]

Essentially the ability to replicate the browser view in WikiProcessors. This could be useful, although the syntax might be unwieldy.

One idea to kick things off:

{{{
#!c +line-numbers
... C code ...
}}}

[Christian Boos]

I once did that, now I have to find where I put the patch ;)

[Christian Boos]

Patch was lost ;-)

WikiEngine refactoring and related fixes postponed.

[Thijs Triemstra <lists@…>]

I like this syntax Sphinx ​uses for this.

[janoscharlipp@…]

Is there a workaround for this?

[chriswillmorris@…]

Is this feature available?

[Nelson Brown <brownnrl@…>]

An example of what code blocks with annotated line numbers can look in a wiki block with some other content around it for context.

[Nelson Brown <brownnrl@…>]

So this is my first crack at contributing to an open source project. I basically read the recommendation that you bite into a bitesized ticket and this was the first one I saw. So what follows is some analysis, and I'd like to get a recommendation from anyone interested. The current mechanism for parsing arguments to WikiProcessors is the parse_processor_args method in trac.wiki.parser module. These currently get stored into self.args as a dictionary of key value paris in the form of processorarg=processorargvalue. So utilizing the existing syntax for passing processor arguments, an example code block with annotated line numbers might look like this: !{{{#!python annotations=lineno import something something.somethingelse() }}} This currently renders (with the arguments ignored) as:

import something
something.somethingelse()

But with the following change to source:trunk/trac/wiki/formatter.py@10865#L321​

formatter.py

@@ -321 +321 @@
                                                     text)
 
     def _mimeview_processor(self, text):
-        return Mimeview(self.env).render(self.formatter.context,
-                                         self.name, text)
+        annotations = self.args['annotations'] \
+        if 'annotations' in self.args and \
+        self.args['annotations'] in ['lineno'] \
+        else None
+        
+        
+        if annotations:
+            return Mimeview(self.env).render(self.formatter.context,
+                                             self.name, text, 
+                                             annotations=[annotations])
+        else:
+            return Mimeview(self.env).render(self.formatter.context,
+                                             self.name, text)
     # TODO: use convert('text/html') instead of render
 
     def process(self, text, in_paragraph=False):

It would render as follows (attached image):

So this is nice, but there are some issues with it. The anchors need to be provided with more context. The line number annoatator was designed for the display of single files, but the anchor needs to know not just the URL, but the comment # / description # / code block # / etc. The link to the eighth line in the fourth code block on the fifth comment might look something like this: #comment:5:codeblock:4:L8. Or something shorter? #c5:cb4:L8 This would mean analyzing the way arguments are passed around to annotator objects, and how to provide that contextual information. This would increase the risk associated with the change as it would be broader. Also, with possible (?) changes to the WikiEngine, I don't know if that is wise? Although this is much less a parsing issue in my (limited) view, but more of a message /argument passing issue. I'll start looking into how to best pass that contextual information, and provide a patch with included tests. I'm all for any feedback though. :)

[Christian Boos]

The topic was revived recently in #10834. Closing in favor of the most recent ticket.