Edgewall Software
Modify

Opened 9 years ago

Closed 8 years ago

Last modified 8 years ago

#2232 closed defect (fixed)

OneLinerFormatter should remove [[BR]]

Reported by: Shunichi Goto <gotoh@…> Owned by: cboos
Priority: normal Milestone: 0.9
Component: wiki system Version: devel
Severity: minor Keywords:
Cc:
Release Notes:
API Changes:

Description

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

     
    623623 
    624624    # Override a few formatters to disable some wiki syntax in "oneliner"-mode 
    625625    def _list_formatter(self, match, fullmatch): return match 
    626     def _macro_formatter(self, match, fullmatch): return match 
    627626    def _indent_formatter(self, match, fullmatch): return match 
    628627    def _heading_formatter(self, match, fullmatch): return match 
    629628    def _definition_formatter(self, match, fullmatch): return match 
    630629    def _table_cell_formatter(self, match, fullmatch): return match 
    631630    def _last_table_cell_formatter(self, match, fullmatch): return match 
    632631 
     632    def _macro_formatter(self, match, fullmatch): 
     633        name = fullmatch.group('macroname') 
     634        if name in ['br', 'BR']: 
     635            return '&nbsp;'             # new line should be removed. 
     636        else: 
     637            return '[[%s]]' % name      # show only macroname. 
     638     
    633639    def format(self, text, out): 
    634640        if not text: 
    635641            return 

Attachments (3)

oneliner_simplify_blocks.patch (4.3 KB) - added by cboos 9 years ago.
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.
oneliner_simplify_blocks.2.patch (3.9 KB) - added by cboos 9 years ago.
Another try, this time replacing blocks by […] or nothing if the block was a comment block. The code is cleaner now. Patch on r2403.
oneliner_simplify_blocks.3.patch (12.8 KB) - added by cboos 9 years ago.
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.

Download all attachments as: .zip

Change History (13)

comment:1 Changed 9 years ago by cboos

  • Owner changed from jonas to cboos

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

comment:2 Changed 9 years ago by cboos

  • Milestone set to 0.9
  • Status changed from new to assigned

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.

Changed 9 years ago by 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.

comment:3 Changed 9 years ago by 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?

comment:4 Changed 9 years ago by 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.

comment:5 Changed 9 years ago by 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 {{{...}}}.

comment:6 Changed 9 years ago by cboos

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

Changed 9 years ago by 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.

comment:7 Changed 9 years ago by cmlenz

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

comment:8 Changed 9 years ago by 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

Changed 9 years ago by 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.

comment:9 Changed 8 years ago by cmlenz

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

comment:10 Changed 8 years ago by cboos

  • Resolution set to fixed
  • Status changed from assigned to closed

Last patch applied in r2413, with minor changes.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed The owner will remain cboos.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from cboos to the specified user.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.