OneLinerFormatter should remove [[BR]]

[Shunichi Goto <gotoh@…>]

I think OneLinerFormatter should remove
. And I also think better that the macro is printed without long arguments. For example, '[[SomeMacro(arg1,arg2,arg3,arg4)]]' ⇒ '[[SomeMacro]]'.

Here is a patch:

formatter.py

@@ -623 +623 @@
 
     # Override a few formatters to disable some wiki syntax in "oneliner"-mode
     def _list_formatter(self, match, fullmatch): return match
-    def _macro_formatter(self, match, fullmatch): return match
     def _indent_formatter(self, match, fullmatch): return match
     def _heading_formatter(self, match, fullmatch): return match
     def _definition_formatter(self, match, fullmatch): return match
     def _table_cell_formatter(self, match, fullmatch): return match
     def _last_table_cell_formatter(self, match, fullmatch): return match
 
+    def _macro_formatter(self, match, fullmatch):
+        name = fullmatch.group('macroname')
+        if name in ['br', 'BR']:
+            return ' '             # new line should be removed.
+        else:
+            return '[[%s]]' % name      # show only macroname.
+    
     def format(self, text, out):
         if not text:
             return

[Christian Boos]

Yes, and we should also remove the #!comment blocks from the oneliner output.

[Christian Boos]

Slightly modified patch applied in r2396.

I'm not closing this ticket now, as I would like to associate some further OneLinerFormatter cleanups, on code blocks this time.

[Christian Boos]

Also simplify blocks in the one liner formatter output. Originally meant for removing the #!comment blocks, but now works on all kind of blocks. A little bit "hackish" though, so tips for improvements are welcomed. Patch on r2403.

[Christopher Lenz]

Do we really need to show the processor type (e.g. #!html) That actually is the least interesting aspect of a code block IMO.

Thinking about it, do we really need to show the {{{...}}} in one-liners? What about simply replacing the whole thing by an ellipsis, and replace by nothing for comments?

[Christian Boos]

I did those changes not in the strict perspective of one-liners, but in the perspective of having a compact wiki output of the whole wiki text, i.e. usually what you would get if you don't do a shorten_line on the input.

One situation where it would be useful is to display the full changeset in the Timeline, as some of my users requested (and there's still an open ticket for that, #48; that would be a configurable setting, of course).

In that use case, I think showing the processor name is valuable information. E.g. you could see if there's a {{{#!diff...}}} or a piece of code {{{#!python...}}} in the text, whereas only showing an ellipsis would completely hide that information.

Maybe the level of block simplification could be set in the OneLinerFormatter.format method. For real one-liners (in combination with shorten_line), what you proposed is better, but for full compact output, I'd prefer my way.

[Christopher Lenz]

I don't agree. One-liners are used mostly in combination with shorten_line right now (and for a reason… longer test isn't really readable when presented as one-liner).

For shortened text snippets, the priority is to display the content that has most value at a glance. Whether a code block uses #!diff or not provides no value except for instructing Trac which kind of formatting to apply. Patches or code snippets will often not even be marked up in such a way, so {{{...}}} could be a patch just as likely as {{{#!diff...}}}.

If we throw out actual prose following a code block in favor of displaying the processor directive, I think that's a mistake.

About how to present such snipped content, I think we should use [...] which is fairly standard for this kind of stuff, and is also more compact than {{{...}}}.

[Christian Boos]

Ok, you convinced me. [...] not only looks prettier, but will make the code simpler :)

[Christian Boos]

Another try, this time replacing blocks by [...] or nothing if the block was a comment block. The code is cleaner now. Patch on r2403.

[Christopher Lenz]

That patch looks okay AFAICT, except that you should use an actual ellipsis (…) instead of "…".

[Christian Boos]

One more thing, if the OneLinerFormatter is presented with a truncated input, it will fail to handle blocks at all, as the closing }}} will most certainly be missing.

I gave a third shot at it: attachment:oneliner_simplify_blocks.3.patch​

[Christian Boos]

Improvement to the previous patch. Now the shorten_line is done after the OneLinerFormatter parsing, so blocks are actually seen in their entirety. Patch on r2409.

[Christopher Lenz]

That last patch looks good AFAICT. Please apply it so we can close this ticket.

[Christian Boos]

Last patch applied in r2413, with minor changes.