Edgewall Software
Modify

Opened 19 years ago

Closed 19 years ago

Last modified 18 years ago

#2232 closed defect (fixed)

OneLinerFormatter should remove [[BR]]

Reported by: Shunichi Goto <gotoh@…> Owned by: Christian Boos
Priority: normal Milestone: 0.9
Component: wiki system Version: devel
Severity: minor Keywords:
Cc: Branch:
Release Notes:
API Changes:
Internal 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 Christian Boos 19 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 Christian Boos 19 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 Christian Boos 19 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 by Christian Boos, 19 years ago

Owner: changed from Jonas Borgström to Christian Boos

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

comment:2 by Christian Boos, 19 years ago

Milestone: 0.9
Status: newassigned

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.

by Christian Boos, 19 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.

comment:3 by Christopher Lenz, 19 years ago

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 by Christian Boos, 19 years ago

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 by Christopher Lenz, 19 years ago

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 by Christian Boos, 19 years ago

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

by Christian Boos, 19 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.

comment:7 by Christopher Lenz, 19 years ago

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

comment:8 by Christian Boos, 19 years ago

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

by Christian Boos, 19 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.

comment:9 by Christopher Lenz, 19 years ago

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

comment:10 by Christian Boos, 19 years ago

Resolution: fixed
Status: assignedclosed

Last patch applied in r2413, with minor changes.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Christian Boos.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Christian Boos to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.