create new tag
, view all tags

Discussion archive for SpacedWikiWordPluginDev

Question: Sometimes you don't want spaces, for example with a product name like CodeWarrior, but you still want it to be a link. The first thing people try is bracket notation, first

The plug-in is too aggressive about adding spaces in these cases. Could it be amended to handle them? ...Meanwhile, the workaround is to do as follows

-- JonReid - 23 Aug 2002

Is there a chance of turning on/off the plugin, depending on the skin? Reasoning: its definitely nicer in print (pdf), but confuses users online. Plus copy&past of wiki words fails.

-- PeterKlausner - 20 Sep 2002

For a minute, I thought I could easily fix this myself. Not so. At least not without ugly globals. What is the proper way to use the URL parameter in the function context, where the TWiki::Plugins::SpacedWikiWordPlugin::spacedWikiWord is hooked in?

-- PeterKlausner - 23 Sep 2002

Unfortunately I don't know, although I agree that 1) it breaks with cut & paste and 2) it would be nice to be able to turn it off.

My users are reasonably happy with it as-is but feel free to modify it. smile

-- MartinCleaver - 23 Sep 2002

I'm just an egg as far as learning Perl, but when the plugin is called, couldn't it test to see if it's on the DisabledPlugins list? Email me if you can identify the reference to "just an egg"! wink

-- StewStryker - 11 Oct 2002

I ran into problems with small tables. On my homepage I have a box with "Most recent changes", and the links in this box kept on running out of the borders. After some time I found out this had to do with non-braking spaces that are put in spaced wiki words. So I changed the spacedWikiWord function in SpacedWikiWordPlugin.pm: I replaced "&nsbp;" with just a blank space. After that my troubles were over.

-- ArthurClemens - 04 Nov 2002

See the attached version of the plugin with following changes:

  1. New variable %TOPICSPACED% inserts topic name spaced out. Use this for titles in the templates of the spaced skins. BTW: this is the behaviour of most "classic" wikis!
  2. Support all-uppercase abbreviations within wiki words,
    e.g. SMTPTransferAgent becomes SMTP Transfer Agent, not SMTPTransfer Agent,
    Odd side effect of this: TWikiDocumentation becomes T Wiki Documentation bug or feature?
  3. New preference variable SPACEDWIKIWORDPLUGIN_DONTSPACE holds comma separated list of words, which should not be spaced
  4. New preference variable SPACEDWIKIWORDPLUGIN_SKINS holds comma separated list of skins, for which the plugin will space all wiki worded links, e.g. print or pdf. This requires the patch to be changed slightly:
    #code added for SpacedWikiWordPlugin
    use TWiki::Plugins::SpacedWikiWordPlugin;
    $theLinkText =
        &TWiki::Plugins::SpacedWikiWordPlugin::spacedWikiWord( $theLinkText )
           if $TWiki::Plugins::SpacedWikiWordPlugin::doSpace;
HTH -- PeterKlausner 5 Feb 2003

I like the revised version of this plugin which PeterKlausner describes above with one exception: rendering TWiki as "T Wiki" is definitely a bug to me. So I edited the regex in his plugin that looks for all-uppercase abbreviations ([A-Z]{+}) to only look for 2 or more uppercase letters together ([A-Z]{2,}). I figure this change doesn't compromise his intent since acronyms will be at least 2 letters long. However, this modification leaves words like TWiki and IMessage alone. Plus, I was pretty darn pleased with myself to figure out the regex (simple as it was). big grin

-- LynnwoodBrown - 06 Mar 2003

This Plugin should only space out WikiWords that are rendered as WikiWords, e.g. words preceeded by a white-space or bracket, regex ([\s\(]). Now it spaces out WikiWords in URLs, breaking the URL. See example bug in GraphicLinkNotWorkingInFormattedSearch

-- PeterThoeny - 10 Mar 2003

Ad link bug: this explains, why some images disappear from print-outs... I'll try to fix this.

Ad T Wiki: There are quite a few cases, where I do want one capital letter prefixed. In a way, this bug-feature reflects the origin: Takefive Wiki -> T Wiki. And: TWiki looks odd as well. See the discussion to RenameTWiki.

Probably the best solution would be to generalize DONTSPACE from a word list to an expression list, although this would be an expensive operation. Then you could add .*TWiki.* to keep its irregular spelling.

-- PeterKlausner - 16 Mar 2003

PeterK - if you can fix the Ad link bug I will roll in your changes to the plugin.

-- MartinCleaver - 20 Apr 2003

I've installed the "patched" version attached to this page and from my experience, the skin sensitive option to space or not isn't working. I checked out the code and the skin detection section in initPlugin is broken. I suggest that the supported exposed functions in TWiki::Func are used for skin detection and thus change the code from this:

    # Is this a skin to space?
    # TBD: is there a way for a plugin to access regular option parsing???
    if ( $ENV{'QUERY_STRING'} =~ /\bskin=(\w+)/ )       # skin there in the first place?
        my $skin = $1;
        my $list = &TWiki::Func::getPreferencesValue( "SPACEDWIKIWORDPLUGIN_SPACESKIN" );
        $doSpace = 1    if $list =~ /\b$skin\b/;
to this:
    # Is this a skin to space?
    my $skin = &TWiki::Func::getSkin();
    my $list = &TWiki::Func::getPreferencesValue( "SPACEDWIKIWORDPLUGIN_SPACESKIN" );
    $doSpace = 1        if $list =~ /\b$skin\b/;

-- StefanLindmark - 04 Jun 2003

A second inspection turns out that the code isn't i18n compliant at all frown so the plugin will break internal links generated by the new i18n stuff in the Feb 03 release. The code uses "old style" [A-Za-z] regexps and getting them out will require non-trivial changes since the locale-related functions and variables aren't exposed through TWiki::Func.

I'll try to fix the following and post the resulting code for review/use:

  • "Ad link" bug (spacing out URLs)
  • Get the code i18n compliant
  • See if there's an (effective) way to change the semantics of DONTSPACE to cover cases where a DONTSPACE word is part of a longer word (e.g. SunTone is DONTSPACE and so should SunToneAtAGlance).

-- StefanLindmark - 04 Jun 2003

OK, now I've attached a new version of the plugin, with the following changes:

  • Only WikiWords are spaced out (no URLs, tags or other)
  • The new code is i18n compliant and honors locale settings in TWiki.cfg. A lot of code had to be blatantly stolen from TWiki.pm, as I suspected.
  • DONTSPACE behavious will now leave specified words untouched in any WikiWord combination.
  • Skin detection now done with official TWiki function calls
  • TWiki never spaced into T Wiki smile
I'm taking this into production and test it myself. Others are welcome to comment or suggest further improvements. Martin, feel free to use this to roll into the official plugin. Specially if somebody would suggest how regexps can be written to allow for precompilation for max performance.

One thing I haven't looked into is if there's a way to get rid of the patching of TWiki.pm -- something I don't really like doing. But I guess this is done with a good reason, so it might not be that easy to avoid ;-).

-- StefanLindmark - 04 Jun 2003

  1. Thanks very much - I'll try it into production tomorrow to test it as well.
  2. I agree that the patch to TWiki.pm is a hack, maybe you could have a look as to whether this should be another MorePluginHooks request?
  3. The hack to read TWiki.cfg is very ugly but I admire your ingenuity. Perhaps you can make an appropriate comment against FuncDotPm as to what extra functionality you would like to be made available?
  4. Testing over the next week notwithstanding I should get the time to update it soon after. If I don't, please feel free to release your changes into a new official version.

-- MartinCleaver - 05 Jun 2003

I've updated SpaceWikiWordPlugin.pm_Stefan with the following fixes:

  • Fixed an bug in the regexp that determines if the word is only a clean wikiword or not
  • A workaround is now in place for a problem where null-padded strings are sent from TWiki::internalLink if the internal link is fully qualified with a web name. This was disturbing the detection of WikiWords in URLs etc.
Will the addition of /o switch at the end of a regexp make it more efficient under mod_perl? If so, there are still places this could be done.

-- StefanLindmark - 06 Jun 2003

I've done a quick experiment using the startRenderingHandler without the TWiki.pm hack. This approach need some other changes to work 100%, but from what I can observe, this could be feasible solution. I'll have to run some tests before going any further to find out if performance loss will terminate this. Without mod_perl, 10 page loads of TWikiPreferences takes 19 seconds with the original hacked hook and 21 seconds with startRenderingHandler. But the mod_perl test will be more interesting since it will probably show larger spread.

-- StefanLindmark - 07 Jun 2003

Hi Stefan, I was getting errors when mailnotify was running:

Use of uninitialized value in pattern match (m//) at ../lib/TWiki/Plugins/SpacedWikiWordPlugin.pm line 71.

Use of uninitialized value in pattern match (m//) at ../lib/TWiki/Plugins/SpacedWikiWordPlugin.pm line 71.
Use of uninitialized value in pattern match (m//) 

... many many times:

This was the fix:

--- SpacedWikiWordPlugin.pm-    2003-06-07 23:53:45.000000000 -0500
+++ SpacedWikiWordPlugin.pm     2003-06-08 00:05:03.000000000 -0500
@@ -68,9 +68,10 @@

     # Get param to turn spacing on/off
     # TBD: is there a way for a plugin to access regular option parsing???
-    $ENV{'QUERY_STRING'} =~ /\bspace=on\b/     and     $doSpace = 1    or
-    $ENV{'QUERY_STRING'} =~ /\bspace=off\b/    and     $doSpace = 0;
+    if ( defined $ENV{'QUERY_STRING'} ) {
+      $ENV{'QUERY_STRING'} =~ /\bspace=on\b/   and     $doSpace = 1    or
+      $ENV{'QUERY_STRING'} =~ /\bspace=off\b/  and     $doSpace = 0;
+    }
     # Get list of special words not to space
     $dontSpaceRegExp = "TWiki";
     if ( $doSpace ) {

Cheers. M.

-- MartinCleaver - 08 Jun 2003

Thanks a lot for testing things! I'm continuing the work on getting the plugin hooked up to startRenderingHandler. The plugin is starting its work in another phase, so there's some new wrapping to be done not to mess up things like URLs and link texts. The development version is currently working, but there are still things to be done to simplify regexps and possibly increase execution speed. I'm fully convinced that this plugin can run without a hack to TWiki.pm smile .

-- StefanLindmark - 08 Jun 2003

I've attached a version of the plugin that doesn't require a hack to TWiki.pm. Functionality is the same as "my" version as of 04 Jun 2003. From my very simple measurements using the command line below, execution time is 20% shorter than the original "hacked TWiki.pm" implementation without mod_perl.

  bash-2.05a$ date;for i in 1 2 3 4 5 6 7 8 9 10; do wget; done;date

-- StefanLindmark - 09 Jun 2003

Well done. Okay, implemented. I'll let you know...

-- MartinCleaver - 09 Jun 2003

cron just said:

Parentheses missing around "my" list at ../lib/TWiki/Plugins/SpacedWikiWordPlugin.pm line 222.

I'd post a patch but it seems to easy!

-- MartinCleaver - 09 Jun 2003

Bad news I'm afraid, Stefan. New versions of TWiki have the WebNameAsWikiName patch applied, but this seems to break with your latest mod. I've reverted to your previous (albeit slower) version for my production system - this solved the problem. Can you apply the WebNameAsWikiName patch on your system and retest?

Also, I concerned about performance for people who don't run under mod_perl. Do you have a set up for which you can speed comparison for them? (Hmm. This seems to be something we should require of the TWikiTestMaster ...)

Many thanks! M.

-- MartinCleaver - 09 Jun 2003

Thanks Martin! Better up, I've updated my test system to the 20030604 alpha and you are right, some things were broken. Things fixed:

  • updated webNameRegex to allow for WebNameAsWikiName
  • plugin now runs without warnings in Apache log
Performance tests were done without mod_perl with wget loading TWikiTutorial 10 times. Note that this measures total time as experienced by the user, which includes client execution and client disk write.
Tested Seconds total Seconds/request Relative execution time
Without plugin 14 s 1.4 s 100%
With plugin 15 s 1.5 s 107%

The "no hack" attachment is now updated with the new code.

-- StefanLindmark - 09 Jun 2003

Added suggested documentation to SpacedWikiWordPluginNextGen documenting new features and normal plugin installation. Also implemented the following changes:

  • Removed %TOPICSPACED% as special variable since it's not needed anymore (%TOPIC% will insert the current topic name which will be spaced out by the plugin).
  • Changed the regexp that chops up the text not to treat <nop> tag as normal HTML that will be skipped
  • WikiWords starting immediately inside of opening parenthesis are now spaced out
Attachment has been updated with new code.

-- StefanLindmark - 09 Jun 2003

I've now performed the same test as above, but with mod_perl running. Note that this was done on a physically different server with a different set of plugins, so the times can't be compared with each other. The test was ran twice before measuring to allow mod_perl to stabilize.

Tested Seconds total Seconds/request Relative execution time
Without plugin 7 s 0.7 s 100%
With plugin 8 s 0.8 s 114%

When it comes to performance, I've seen that the TWiki code uses constructs like this:

    $theTopic =~ s/^\s*//;
    $theTopic =~ s/\s*$//;
instead of something like this:
    $theTopic =~ s/^\s*(.*)\s*$/$1/;
Without being a Perl performance guru, one would assume that it would be desirable to minimize the number of regexps going through the text. But since the code is mature, I guess there's somebody out that can tell me why this assumption is wrong smile .

-- StefanLindmark - 09 Jun 2003

Bzzzt! If you don't try, you'll never know:

bash-2.05a$ time perl -e '$f=" Stefan "; $f =~ s/(e)(f)/$2$1/;for($i=0;$i<1000000;$i++){$f=" Stefan ";$f =~ s/^\s*(.*)\s*$/$1/o;}'

real    0m15.459s
user    0m12.460s
sys     0m0.090s

bash-2.05a$ time perl -e '$f=" Stefan "; $f =~ s/(e)(f)/$2$1/;for($i=0;$i<1000000;$i++){$f=" Stefan ";$f =~ s/^\s*//o; $f =~ s/\s*$//o;}'

real    0m11.470s
user    0m9.090s
sys     0m0.050s

(similar results on consecutive runs)
So two simpler regexps are actually faster than one complex, just because of the reference variable. (Note the first substitution which is there to make sure that perl isn't too smart during the test and compiles simpler internal handling of regular expressions.)

I second Martins call for a testing function/person and one item on that list should be performance testing. Throw in a handful of plugins and TWiki could end up being a real hog in your system.

-- StefanLindmark - 09 Jun 2003

Fixed the code to leave WikiWords unspaced inside <a ....>....</a> tag pairs. I'm starting to long for that special hook that only handles the internal link rendering smile .

-- StefanLindmark - 09 Jun 2003

Well, if you can code up patch to the core then that is what you should do. There is too much working around deficiencies in the core as it is and the CoreTeam are very reluctant to code things on our behalf. Attach a page to MorePluginHooks and try it.

Also (I didn't check), if performance testing isn't mentioned on the TWikiTestMaster responsibilities then perhaps you can add it?

Finally - am I supposed to remove the patch from the core to use the new version? What happens if I don't?

-- MartinCleaver - 12 Jun 2003

Much as I would like to, unfortunately I won't have the time to get a new hook patch coded and tested in at least two months. I've been running my modified plugin in a production environment for a month now. Slight side-effects can be introduced in complicated situations like including an HTML pulldown-menu definition from one topic into the Gnu skin framework/navigation itself, plus some other places that have been cosmetic only. Nevertheless, I think the right way in the long run will be to go through a proper hook. I might code it, but that would be September timeframe in that case since this work is currently not funded in any way.

-- StefanLindmark - 08 Jul 2003

Great, thanks, no problem. I look forward to seeing it in September.

-- MartinCleaver - 09 Jul 2003

I have tried the latest Stephan's version (whitout the hack) and I notice a misfeature that create links in <noautolink> sections. You could see that on the TWiki06x00.TextFormattingRules page, at the bottom of the big table. To solve that issue, the large regexp at the end of the plugin code should be completed to ignore section between <noautolink> and </noautolink> (case-insensitive).

-- DenisGervalle - 12 Aug 2003

Minor feature request. The code above seems to work very well for me (Thanks!), however, if I create a heading which is a wiki word, then create a TOC using the % TOC % syntax, I notice that the word in the TOC does not get spaced.

Would be nice if the TOC had spaces added also.

-- EdWildgoose - 14 Aug 2003

You know, with the spaced wiki words plugin, the signature shown below the edit box (for copy and pasting) is broken? It no longer reads:
-- Main.TorbenGB - 18 Aug 2003 <== This is your signature for easy copy & paste operation
but rather:
-- Main.Torben GB - 18 Aug 2003 <== This is your signature for easy copy & paste operation

See the difference?

-- TorbenGB - 18 Aug 2003

Hmm. I agree the spaced sig sounds broken. A short term fix would be to add <nop> before the sig lines in the view.tmpl file. A longer term solution would be to support Arthur's proposal to have underscores accepted in WikiWords.

WRT TOC: I imagine this is not fixable because TOC is implemented by the core, not by a plugin. As a guess it would get invoked too late. If the core gets rationalised then this is a candidate for change. I certainly agree that it is nice to have.

WRT noautolink: This is Stefan's ball.

-- MartinCleaver - 18 Aug 2003

Hmm. I don't agree, that the spaced sig is broken: by definition, all wiki words are spaced out and thus not available for copy & paste any more. An exception from this rule just for the signature does not belong into the plugin code. It's cleaner (and easier) to <nop> this in the template, IMHO.
Hmm. Isn't it <nop>ed anyway, so that it's not turned into a link?

For easier copy & paste in online skins, just don't list them in the preference SPACEDWIKIWORDPLUGIN_SPACESKIN

Ad <noautolink>: I was not even aware of this new feature. I guesstimate, that the patch-less version of this plugin has to re-do too much of TWiki's job and trips up on this obscure feature.

-- PeterKlausner - 18 Aug 2003


I just coded a small patch to TWiki.pm to use the plugin to expand a new variable %SPACEDTOPICP%. I need it to expand topic names in window title, as we are setting up a ggogle-like search engine in our intranet (aspseek), and the weight of the title is important, and having non-meaningful window names perturbates the relevance calculations

Note the implementation: I reuse the %SPACEDTOPIC% var code to do it without runtime overhead... (old line in red, new in green)

    $_[0] =~ s/%SPACEDTOPIC%/&handleSpacedTopic($_[1])/ge;
    $_[0] =~ s/%SPACEDTOPIC(P?)%/&handleSpacedTopics($1,$_[1])/ge;
Note that this should be generalized in my opinion, to get a huge boost in perfs for big topics: have only one search for all the %([A-Z_0-9]+[{](.*?)[}]% forms in one pass, and decode things if found.

-- ColasNahaboo - 03 Nov 2003

One suggestion: use CSS. I explain:

  • make the core engine issue autolinks as:
    <a class=TWautolink >... (plain wikiwords)
    <a class=TWforcedlink >... (for [[...]])
  • then the plugin is free to handle all the
    <a class=TWautolink in its regexp, not just <a .*
Basically CSS is offering a way to add semantics to the rendering, always useful (this A tag is one serving this purpose). Of course, signatures will not have this class. And A tags in <noautolink> sections will not have the CSS class TWautolink...

Actually, all HTML tags issued by the TWiki engine and plugins should have (unique) CSS classes...

-- ColasNahaboo - 31 Dec 2003

The latest SpreadSheetPlugin has now a $PROPERSPACE() formula that spaces out WikiWords.

-- PeterThoeny - 07 Mar 2004

Bug in newest TWiki release with latest plugin version?

Having installed the latest rev of Twiki (released just a couple weeks ago at the start of Sept '04) and the latest rev of this plugin (dated March) I find that the plugin is properly spacing all same-web WikiWords (without a "webname." prefix) but fails to space out those which are referenced in other webs. Not sure how to fix this. Any help appreciated. Thanks!

-- MarkTaylor - 17 Sep 2004

The reason for this problem is an improper handling of $TranslationToken in Render.pm. See the discussion in TranslationTokenPassedIntoSubroutines.

-- ThomasWeigert - 11 Feb 2005

QUESTION? Would you recommend the patch from TranslationTokenPassedIntoSubroutines as a solution to the problem Mark describes above ? Or, is it rather suggested to accept that the plugin fails to space out those which are referenced in other webs.

-- KeithHelfrich - 03 Jul 2005

Next Update?

Relative to the recent release of the TWiki engine itself, this plugin is old. The above version seems to not work properly in a few areas when used with the latest TWiki release. I see there has been a lot of discussion and development of enhancements, hacks, and rehacks since this 04/04 release was offered. When will a roll-up or re-release of this plugin be done which encompasses all recent Dev modifications, and which is verified to work against the latest Twiki engine? Thanks.

-- MarkTaylor - 23 Sep 2004

I'm looking at this now. I don't recall having seen the note beforehand - but to be honest I've only just had a need to solve this today.

-- MartinCleaver - 04 Dec 2004

Ok. The problem is that internalLink, called and defined in RenderDotPm is the place where the call to RenderedWikiWordHandler occurs. However, by the time it is called, it does not know whether it has occurred inside a [[]] construct, as a Web.Topic, etc. So the test that is applied is simply "does this look like a WikiWord?": this interprets inside a forced link, and does not match a specificweb link.

internalLink / specificLink needs unravelling. Sadly, it could be more trouble than it's worth.

Render.pm defines a sub called internalLink:

        return internalLink( $thePreamble, $theWeb, $theTopic, $theWeb, $theAnchor, $doLink );
        return internalLink( $thePreamble, $theWeb, $theTopic, $theLinkText, $theAnchor, $doLink );
        return internalLink( $thePreamble, $web, $topic, $theText, $anchor, 1 );

-- MartinCleaver - 05 Dec 2004

%SPACEDTOPICP% upgraded for Cairo.

-- ColasNahaboo - 05 Jan 2005

I think the key problem is that the Plugin does not honor TWiki's rule for WikiWord linking. WikiWords are defined as UPPERlowerUPPER pattern prefixed by whitespace, parenthesis or ][. That is, the spacing should only be done for words with those prefixes. That avoids many problems, such as spacing words in URLs etc. This is how SpreadSheetPlugin#FuncPROPERSPACE works.

-- PeterThoeny - 06 Jan 2005

I've just updated DevelopBranch so that it calls the handler less aggressively (as per my posting 5 Dec 2004). Once I have tested it I will report again.

-- MartinCleaver - 16 Feb 2005

Martin, we were discussing in Codev.UnderscoreWikiWords to enhance this plugin to deal with underscore wiki words. It would be a shame to multiply this functionality. Would you be interested?

I think we would need 2 preference settings to deal with the 2 kind of links: SPACEOUTUNDERSCOREWIKIWORDS and SPACEOUTCLASSICWIKIWORDS so users can choose which links to space out.

-- ArthurClemens - 17 Apr 2005

It needs a complete rewrite. Now I've tidied RenderDotPm#renderWikiWord it should be much easier to make it hookable. I've no current plan to do this immediately but am happy to look at a code proposal though.

-- MartinCleaver - 17 Apr 2005

Just installed this on a Dakar install... seems to work fine. Credit goes to whoever finished cleaning up TWiki's Render.pm routine!

-- MartinCleaver - 10 Jul 2006

(In case its different, I should add that I used the version from SVN)

-- MartinCleaver - 10 Jul 2006

Could someone check if the Plugin topic has the latest version from SVN TWiki 4 branch, and update the topic & form if needed?

-- PeterThoeny - 10 Jul 2006

There is a small difference between the uploaded zip and the SVN version.

But as far as I can see it is only related to $VERSION and $RELEASE. No code has changed.

However the renderWikiWordHandler has changed from Cairo to TWiki4. This is the only plugin that uses it!

The change is that in Cairo both WikiWords and [[WikiWords]] were sent to the handler. In TWiki4 only WikiWords becomes Wiki Words. WikiWords in square brackets are no longer spaced out.

Normally this would not be a big issue because if you put a wikiword in brackets you probably want it rendered like that. But if you make formatted search where $topic is used and you sometimes have a non-wikiword you may want to use the [[ ]] notation.

Personally I do not find this plugin to work very well. It turns TWiki into T Wiki for example. If you read the above descriptions of problems reported the last years you will find that the plugin has its problems in practical use.

But if you can live without the spaced [[WikiWords]] then it does work in TWiki-4.0.4.

Looking at the code. This plugin will not handle internationally named topic names. The regexes are all written for English only.

-- KennethLavrsen - 10 Jul 2006

It looks like this Plugin needs some work. Are [[link][WikiWordLabel]] spaced out? Probably should not. I think the proper behaviour for WikiWord links is to generate a Wiki Word link.

On spacing rule, this calls for an exception table or list to keep some words "as is", such as TWiki, RedHat, McConnald etc.

-- PeterThoeny - 11 Jul 2006

If you'd want it to expand those [] links as well, then its not the plugin that needs modifying, it's TWiki. You'd need to call

    $text = $this->{session}->{plugins}->renderWikiWordHandler( $text ) || $text;
From within _handleSquareBracketedLink as well as _handleWikiWord

I'd imagine this line would need inserting around line 742 of http://develop.twiki.org/svn/twiki/branches/TWikiRelease04x00/lib/TWiki/Render.pm

An exception table could indeed be implemented in the plugin if so desired.

-- MartinCleaver - 11 Jul 2006

Just a note, first to say that I love this plugin -- it makes my twiki site readable.

Second, to point out that wiki words with anchors seem to miss out on the luxury of being spaced. For example SpacedWikiWordPlugin#Plugin_Info does not get spaced

-- KeithHelfrich - 19 Jul 2006

It would be very nice to maintain a global list of WikiWords that should not be spaced.

-- KeithHelfrich - 07 Oct 2006

There is already an existing DONTSPACE TWikiPreferences setting provided for the SpreadSheetPlugin's $PROPERSPACE() function that can be leveraged.

-- PeterThoeny - 07 Oct 2006

Tested in 4.0.5. TWiki displays as TWiki if you do the following.

-- SteveStark - 16 Nov 2006

Steve, what does that change supposed to do? The '2' in [A-Z\s]2, does not look right.

-- PeterThoeny - 16 Nov 2006

'1' would split TWiki as T Wiki. '2' would not split TWiki because the first i in TWiki is not uppercase. My study suggests that + refers to any number. Therefore, + changes TWiki to T Wiki.

-- SteveStark - 17 Nov 2006

With your regex you are scanning for one A-Z or space char, followed by a literal "2" and a ",". What you intend is probably: ([A-Z\s]{2,})

-- PeterThoeny - 17 Nov 2006

Is there an error in the code because that is what I was intending?

-- SteveStark - 18 Nov 2006

I have not tried this plugin, and do not exactly know what you try to do. I just wanted to point out that ([A-Z\s]2,) probably does something unintended since it scans for one upper case char or one space, followed by the literal number 2, and a comma. In contrast, ([A-Z\s]{2,}) scans for any two or more upper case chars or spaces.

-- PeterThoeny - 18 Nov 2006

([A-Z\s]{2,}), ([A-Z\s]2,), ([A-Z\s]2) all have the same results. Yes, the , in the code is not necessary

-- SteveStark - 19 Nov 2006

Does anyone have a SPACEDTOPICP.patch for 4.1.2?

-- EdwardSandstig - 22 Mar 2007

What does this plugin do more than what can be done with %SPACEOUT{}%?

-- ArthurClemens - 01 Apr 2007

It doesn't require you to write %SPACEOUT anywhere. Wikiwords are automatically spaced out e.g. AbCdEf appears as Ab Cd Ef.

The same REs (for recognising and splitting wikiwords) are now duplicated in three places (SpreadSheetPlugin, the core, and this plugin). Someone should rationalise that.

-- CrawfordCurrie - 02 Apr 2007

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatpatch SPACEDTOPICP-cairo.patch r1 manage 1.5 K 2005-01-05 - 18:46 ColasNahaboo %SPACEDTOPICP% for Cairo
Unknown file formatpatch SPACEDTOPICP.patch r1 manage 1.4 K 2003-11-03 - 12:58 ColasNahaboo patch to lib/TWiki.pm to add var %SPACEDTOPICP%
Perl source code filepm SpacedWikiWordPlugin.pm r1 manage 3.4 K 2003-03-04 - 22:51 PeterKlausner patched for %TOPICSPACED% et al
Unknown file formatpm_Stefan SpacedWikiWordPlugin.pm_Stefan r2 r1 manage 7.9 K 2003-06-06 - 12:07 StefanLindmark Modified plug (see comments by Stefan on 04 June)
Unknown file formatpm_nohack SpacedWikiWordPlugin.pm_nohack r6 r5 r4 r3 r2 manage 9.1 K 2003-06-09 - 22:24 StefanLindmark Version of the plugin without hack to TWiki.pm
Topic revision: r1 - 2007-05-04 - ArthurClemens
  • 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-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.