Feature Proposal: Provide option to disable numbers in WikiWords

Motivation

Motivation described in DisableWikiWordsWithNumbers

Description and Documentation

The current TWiki code changed to treat numbers in WikiWords as lower case letters. This request is to provide an configuration option to choose between the current way or the old way.

Please see the comments in the above referenced support page. The option can be in the configure page or as a global setting variable.

Examples

Impact

WhatDoesItAffect:

Prefs %WHATDOESITAFFECT%

edit

Implementation

-- Contributors: AlanDayley - 06 Sep 2007

Discussion

I agree to this one for a 5.0 or maybe even a 4.2.1 patch release.

We have feature freeze so I do not want anyone to add this in 4.2.0

It would be a configure setting.

But Alan. A quick hack in the Perl code is in lib/TWiki.pm

Find the line

    $regex{wikiWordRegex} = qr/[$regex{upperAlpha}]+[$regex{lowerAlphaNum}]+[$regex{upperAlpha}]+[$regex{mixedAlphaNum}]*/o;

And change it to

    $regex{wikiWordRegex} = qr/[$regex{upperAlpha}]+[$regex{lowerAlpha}]+[$regex{upperAlpha}]+[$regex{mixedAlphaNum}]*/o;

It is easy to add this to TWiki.pm controlled by a configure setting.

But it is a little harder (for me) to make the Javascript configurables and there are a few scripts that also uses a similar definition.

I would commit to do the Perl part.

But remember. Not for 4.2.0!

-- KennethLavrsen - 06 Sep 2007

For the record, the original motivation for enabling numbers in WikiWords in TWiki are in ProposedChangeToWikiWordSpec and decision in EdinburghReleaseMeeting2006x07x18.

The last change to the wikiword spec was a lesson learned, and I am reluctant to touch the default spec again.

A configuration option sounds ok to me (as suggested).

-- SteffenPoulsen - 06 Sep 2007

Thanks for the tip, Kenneth. I noticed PeterThoeny documented that change in a comment to my support request at DisableWikiWordsWithNumbers.

Since I made this request one of the engineers came over and praised the new functionality as something he has wanted for some time. I guess which ever way a new option is set, some will want it the other way.

Thanks for the rapid consideration on this suggestion.

-- AlanDayley - 07 Sep 2007

I just discovered an unfortunate and unintended side effect of the hack to lib/TWiki.pm. One of my TWiki pages is a FAQ document with lots of questions at the top with anchor links to the answers further down the page. The page source looks something like this:

   [[#MyAnchor1][1]]. This is question #1
   [[#MyAnchor2][2]]. This is question #2
   [[#MyAnchor3][3]]. This is Question #3
   ...
   #MyAnchor1
   Here is the answer to question #1

   #MyAnchor2
   Here is the answer to question #2

   #MyAnchor2
   Here is the answer to question #3
   

The rendered HTML produced by the hacked lib/TWiki.pm program looks like this:

   <a href="/TWiki/bin/view/Myweb/MyFaq#MyAnchor1" class="twikiCurrentTopicLink twikiAnchorLink">1</a>. This is question #1
   <a href="/TWiki/bin/view/Myweb/MyFaq#MyAnchor2" class="twikiCurrentTopicLink twikiAnchorLink">2</a>. This is question #2
   <a href="/TWiki/bin/view/Myweb/MyFaq#MyAnchor3" class="twikiCurrentTopicLink twikiAnchorLink">3</a>. This is question #3
   ...
   <a name="MyAnchor"></a>1
   Here is the answer to question #1<p />
   <p />

   <a name="MyAnchor"></a>2
   Here is the answer to question #2<p />
   <p />

   <a name="MyAnchor"></a>3
   Here is the answer to question #3<p />
   <p />

So you can see that MyAnchor1 gets rendered as <a name="MyAnchor"></a>1, which breaks the linkage, of course, since it no longer matches the anchor created at the top of the page.

I would like to be able to disable WikiWords with numbers, as the hack provides, but still allow numbers to appear in anchors. I understand that anchors are supposed follow the same naming convention as WikiWords, but technically speaking, they are not WikiWords, since they don't link to external topics. Therefore it seems to me that anchors shouldn't be subjected to the same rules as true WikiWords.

At any rate, the mis-rendered HTML looks like a bug to me.

-- BarryLake - 10 Dec 2007

My hack (which was untested) was simply wrong. I had edited two places but should only have edited one place.

The correct string to change to is

$regex{wikiWordRegex} = qr/[$regex{upperAlpha}]+[$regex{lowerAlpha}]+[$regex{upperAlpha}]+[$regex{mixedAlphaNum}]*/o;

Sorry for the mistake. I also corrected it in the text above in case someone read it there and do not bother reading the whole page.

If the community agrees I can implement this with a configure setting in the "Miscellaneous settings" called {NumbersAreLowerCaseLettersInWikiWords} (feel free to propose better name) which per default is enabled and an expert setting.

But for GeorgetownRelease.

-- KennethLavrsen - 10 Dec 2007

How about a shorter name {AlphaNumWikiWords}?

Since this spec change in 4.0 had wide implications I suggest to take this into the 4.2.1 patch release. This is a small and safe change that solves problems for existing users. Question is, what is the default, the old way or the 4.x way?

-- PeterThoeny - 10 Dec 2007

Thanks, Kenneth. That did the trick!

-- BarryLake - 10 Dec 2007

To keep the change as non-interfering as possible, I suggest to keep the 4.x default.

-- SteffenPoulsen - 11 Dec 2007

{AlphaNumWikiWords} is a good name and for sure it has to be enabled by default to avoid yet another upgrade obstacle for the poor admins.

-- KennethLavrsen - 11 Dec 2007

Accepted by 14-day rule with the suggested changes by Peter and Steffen.

• {AlphaNumWikiWords}
• Configure parameter that enables numbers as lower case letters in the wikiword rule
• Default enabled to maintain compatibility with current release
• Georgetown release
• Kenneth implements

Note that it is my own proposal I declare accepted so feel free to be extra critical of this decision.

-- KennethLavrsen - 25 Dec 2007

No need to be extra critical, you do a lot for the community!

This is a small and safe change, I could make it into the 4.2.1 release. I see this on the borderline of a bug fix and an enhancement.

-- PeterThoeny - 01 Jan 2008

This is far behind the curve. It was accepted for TWiki, as a means to maintain compatibility. Things have moved on (we lived with the upgrade pain) so I changed state from Accepted to Rejected.

-- CrawfordCurrie - 21 Feb 2012

Commenting is disabled while not logged in