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

[cboos]

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

[cboos]

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.

[cboos]

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.

[cmlenz]

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?

[cboos]

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.

[cmlenz]

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 {{{...}}}.

[cboos]

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

[cboos]

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

[cmlenz]

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

[cboos]

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​

[cboos]

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.

[cmlenz]

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

[cboos]

Last patch applied in r2413, with minor changes.