Tags:
create new tag
, view all tags

RicherSyntaxPluginDev Discussion: Page for developer collaboration, enhancement requests, patches and improved versions on RicherSyntaxPlugin contributed by the TWikiCommunity.
• Please let us know what you think of this extension.
• For support, check the existing questions, or ask a new support question in the Support web!
• Please report bugs below

Feedback on RicherSyntaxPlugin

There are problems with the "continuation" backslash.

-- FrancoBagnoli - 29 Mar 2002

Very good idea. The more the (t)wiki syntax is mailable to non-wikiers in ascii emails, the better!

A patch and a suggestion:

  • IgnoringHeader.patch: Ignores contents of tag no to mess headers, otherwise skins with CSS get badly mangled
  • It would be nice to be able to have a shorthand for inserting just a single
    for allowing a simple break in items. Maybe if the breaking line has just dots, make the break vertical space proportional to the number of dots?

-- ColasNahaboo - 24 Apr 2002

There is a discrepancy between the documentation and the code with regards to the H3 headers: The doc says to underline with "~~~~", but the code says to use "^^^^". One of the should be changed.

We might as well add an H4 utilizing one or the other, as in, e.g.,

      # header      
      # ^^^^^^               => <H3>

      $_[0] =~ s/(^([ \t]*)(\w.+)([ \t\r]*\n)\2(\^+))/abs(length($3)-length($5))<=1?"---\+\+\+ $3\r\n":$1/gem;

      # header      
      # ~~~~~~               => <H4>

      $_[0] =~ s/(^([ \t]*)(\w.+)([ \t\r]*\n)\2(~+))/abs(length($3)-length($5))<=1?"---\+\+\+\+ $3\r\n":$1/gem;

-- ThomasWeigert - 12 May 2002

Thanks, and sorry for the delay in my answer.

I inserted your patch in the current version.

-- FrancoBagnoli - 14 May 2002

I believe that there might be a problem in RicherSyntaxPlugin.pm at the line for processing old-style descriptions. Line 75 starts with

$_[0] =~ s/^(\t+)(\w\S*?):\s/"<dt> $2<\/dt><dd>" . &Twiki::emitList ( "dl", "dd", length $1 )/gme;

This line causes a problem with formatting if headings are following a description. A test case is attached. If I omit this line, everything seems to be working fine.

However, if this line does serve a purpose, maybe the "dl" in the call to emitList should be changed to "dt"?

-- ThomasWeigert - 16 May 2002

I ran into an interaction between this plugin and XpTrackerPlugin in that the variable XPSHOWPROJECTCOMPLETIONBYSTORIES displays a table incorrectly (see XpTrackerPluginDev) when RicherSyntaxPlugin is enabled.

-- ThomasWeigert - 03 Nov 2002

This problem (03 Nov 2002) can be traced to a bug in documentation for RicherSyntaxPlugin. The following rule is stated:

  • Every two lines in which the second one has greater indentation (more white space at beginning) and does begins with a letter (in order to avoid clashes with nested lists) are glued together
However, this is also true for, e.g., "|" which by most accounts does not qualify as a letter. See Example 2 in RicherSyntaxPlugin for this situation. In fact, the only situations which do not seem to become glued together are
  • lists
  • ...
  • only white space
  • indentation after a break
The wording in the documentation should be corrected.

-- ThomasWeigert - 03 Nov 2002

checked .zip into CVS (not below patch)

-- WillNorris - 15 Feb 2005

The "compatability" with the way heafings are done in e-mail makes this very attractive for my users, but I've found a problem that blows it up when used with DEVELOP for Dakar and is in fact a backward compatability problem.

Look at lines 29 and 32 in initPlugin():

     18 sub initPlugin
     19 {
     20     ( $topic, $web, $user, $installWeb ) = @_;
     21
     22     # check for Plugins.pm versions
     23     if( $TWiki::Plugins::VERSION < 1 ) {
     24         &TWiki::Func::writeWarning( "Version mismatch between RicherSyntaxPlugin and Plugins.pm" );     25         return 0;
     26     }
     27
     28     # Get plugin preferences, the variable defined by:          * Set EXAMPLE = ...
     29     $exampleCfgVar = &TWiki::Prefs::getPreferencesValue( "RICHERSYNTAXPLUGIN_EXAMPLE" ) || "default        ";
     30
     31     # Get plugin debug flag
     32     $debug = &TWiki::Func::getPreferencesFlag( "RICHERSYNTAXPLUGIN_DEBUG" );
     33
     34     # Plugin correctly initialized
     35     &TWiki::Func::writeDebug( "- TWiki::Plugins::RicherSyntaxPlugin::initPlugin( $web.$topic ) is O        K" ) if $debug;
     36     return 1;

As you see, there is the call to TWiki::Prefs::getPreferencesvalue which should be a call to TWiki::Func::getPreferencesvalue .

The note at the top of EmptyPlugin.pm -- which I take to be the tempalte for developing plugins -- say that only TWiki::Func (lib/TWiki/Func.pm) should be used.

Never the less, I'm unclear as to why the getPreferencesValue and getPreferecnesFlag functions are duplicated in TWiki::Prefs (lib/TWiki/Prefs.pm).

-- AntonAylward - 08 Mar 2005

And another ...

On line 77 of RicherSyntaxPlugin.pm there is a call to the undocumented) innards of TWiki rather than the "Func" interface. This time it is to TWiki::emitList() Which is interesting as it really should be TWiki::Render::emitlist()

ThomasWeigert mentioned a problem with this expression above, but I've tried to look a bit deeper.

Looks like that needs some more testing.

-- AntonAylward - 08 Mar 2005

This plugin break in the Dakar/DEVELOP. See DakarReleaseNotes#Space_Tab_conversion for the reason.

-- AntonAylward - 17 Mar 2005

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatpatch IgnoringHeader.patch r1 manage 0.9 K 2002-04-24 - 17:22 ColasNahaboo Ignores contents of tag no to mess headers
Edit | Attach | Watch | Print version | History: r16 < r15 < r14 < r13 < r12 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r16 - 2005-03-17 - AntonAylward
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.