Item10907: Whitespace effecting delayed CALC in search results unexpectedly.

Here is some bizarre behavior that I can't explain. I think it's wrong (hence the task), but I'd at least like an explanation.

I have a %SEARCH that finds a couple of topics and displays links. With it formatted for readability, none of the macros are expanded except the SEARCH; one gets an ugly mess. But the same SEARCH - exactly - with the end-of-lines removed works. Here is a version - minimally changed so it finds items instead of calendars. Note that in the failing case, I changed the search to just 1 digit - that's so this topic doesn't take several minutes to display. It's not the trigger for this behavior.

• Version 1 - no end-of-lines. I know items aren't calendars, but it will find a couple that match.

<sticky>%CALC{$SET($ThisYear,$EVAL(%DISPLAYTIME{"$year"}%+0))}% 
%CALC{$SET($NextYear,$EVAL(%DISPLAYTIME{"$year"}%+1))}%</sticky>
   * Current Family Calendars <sticky>%<nop>SEARCH{   "Item\d\d\d\d$"   web="%WEB%"   scope="topic"   regex="on"   nonoise="on"   casesensitive="on"   reverse="off"   separator=" "    nofinalnewline="on"   format="$percntCALC{\"$IF($OR($EXACT($GET($ThisYear),$VALUE($REPLACE($topic,1,$EVAL($LENGTH($topic)-4)))),                                                     $EXACT($GET($NextYear), $VALUE($REPLACE($topic,1,$EVAL($LENGTH($topic)-4))))),                                              [[$web.$topic][$REPLACE($topic,1,$EVAL($LENGTH($topic)-4))]], <nop>)\"}$percnt"
 }%</sticky>

• Current Family Calendars %SEARCH{ "Item\d\d\d\d$" web="Tasks" scope="topic" regex="on" nonoise="on" casesensitive="on" reverse="off" separator=" " nofinalnewline="on" format="$percntCALC{\"$IF($OR($EXACT($GET($ThisYear),$VALUE($REPLACE($topic,1,$EVAL($LENGTH($topic)-4)))), $EXACT($GET($NextYear), $VALUE($REPLACE($topic,1,$EVAL($LENGTH($topic)-4))))), $REPLACE($topic,1,$EVAL($LENGTH($topic)-4)), )\"}$percnt" }%

• Version 2 - would be a whole lot easier to maintain - but look at the mess! (Imagine (or try) it with all 4 digits :-()

<sticky>%CALC{$SET($ThisYear,$EVAL(%DISPLAYTIME{"$year"}%+0))}%
%CALC{$SET($NextYear,$EVAL(%DISPLAYTIME{"$year"}%+1))}%</sticky>
   * Current Family Calendars <sticky>%<nop>SEARCH{
   "Item\d$"
   web="%WEB%"
   scope="topic"
   regex="on"
   nonoise="on"
   casesensitive="on"
   reverse="off"
   separator=" "
   nofinalnewline="on"
   format="$percntCALC{\"$IF($OR($EXACT($GET($ThisYear),$VALUE($REPLACE($topic,1,$EVAL($LENGTH($topic)-4)))),
                                 $EXACT($GET($NextYear),$VALUE($REPLACE($topic,1,$EVAL($LENGTH($topic)-4))))),
                                                [[$web.$topic][$REPLACE($topic,1,$EVAL($LENGTH($topic)-4))]], <nop>)\"}$percnt"
 }%</sticky>

• Current Family Calendars %SEARCH{ "Item\d$" web="Tasks" scope="topic" regex="on" nonoise="on" casesensitive="on" reverse="off" separator=" " nofinalnewline="on" format="$percntCALC{\"$IF($OR($EXACT($GET($ThisYear),$VALUE($REPLACE($topic,1,$EVAL($LENGTH($topic)-4)))), $EXACT($GET($NextYear),$VALUE($REPLACE($topic,1,$EVAL($LENGTH($topic)-4))))), $REPLACE($topic,1,$EVAL($LENGTH($topic)-4)), )\"}$percnt" }%

-- TimotheLitt - 21 Jun 2011

Hi Timothe, this is most likely due to the fact that CALC is warty as a warty thing

It (ab)uses commonTagsHandler quite severely. So, try enabling its registerTagHandler equivalent ('SSP'), uncomment these lines:

diff --git a/lib/Foswiki/Plugins/SpreadSheetPlugin.pm b/lib/Foswiki/Plugins/SpreadSheetPlugin.pm
index a2a4bca..28b98c8 100755
--- a/lib/Foswiki/Plugins/SpreadSheetPlugin.pm
+++ b/lib/Foswiki/Plugins/SpreadSheetPlugin.pm
@@ -38,16 +38,16 @@ sub initPlugin {
     # CALC but in a tag handler instead of in commonTagsHandler. That means
     # you can't use table references, but you can rely on the execution order
     # relative to other macros.
-#    Foswiki::Func::registerTagHandler(
-#        "SSP",
-#        sub {
-#            my ( $session, $attributes, $topic, $web ) = @_;
-#            require Foswiki::Plugins::SpreadSheetPlugin::Calc;
-#            $Foswiki::Plugins::SpreadSheetPlugin::Calc::rPos = 0;
-#            $Foswiki::Plugins::SpreadSheetPlugin::Calc::cPos = 0;
-#            return Foswiki::Plugins::SpreadSheetPlugin::Calc::doCalc(
-#                $attributes->{_DEFAULT});
-#        });
+    Foswiki::Func::registerTagHandler(
+        "SSP",
+        sub {
+            my ( $session, $attributes, $topic, $web ) = @_;
+           require Foswiki::Plugins::SpreadSheetPlugin::Calc;
+            $Foswiki::Plugins::SpreadSheetPlugin::Calc::rPos = 0;
+            $Foswiki::Plugins::SpreadSheetPlugin::Calc::cPos = 0;
+            return Foswiki::Plugins::SpreadSheetPlugin::Calc::doCalc(
+                $attributes->{_DEFAULT});
+        });
 
     # Flag to skip calc if in include
     $skipInclude =

Of course, the SSP macro won't be useful in a TML table, but many CALCulations (such as yours) aren't table related anyway.

I'm a big fan of spacing out macros like this (in fact I tried to space-out most of our macro usage in the default Foswiki topics/documentation), so I can relate to your frustration.

So, I try to avoid CALC at all costs, and I do this by:

• Using core IfStatements
• Using core VarQUERY for arithmetic ops, which also has a length() operator (among others, see QuerySearch)
• Using core VarFORMAT for basic list processing
• FilterPlugin's FORMATLIST for more (regex) list processing

Unlike CALC, all these macros behave predictably and can be delayed safely because they are using registerTagHandler instead of commonTagsHandler to register their macros.

-- PaulHarvey - 22 Jun 2011

Sorry for the slow response, I've been stretched a bit thin.

It turns out that there's a simple, if undocumented solution found by reading code...

If the CALC lines are continued with \ (backslash) before newline, the problem disappears!

It's not obvious why CALC doesn't just assume the \ (after all, the string is quoted). But I decided to accept success...

Unless someone has a good reason for why CALC requires the \, it would be good to remove the requirement for it. Otherwise, perhaps this could be documented

I'm not sure how I could solve my actual problem without CALC - I didn't see an operator for "this year +1".

The more interesting case is where I build a list of links to all the the calendars I can find that are not this year or next. That uses a similar CALC to filter out this year and next, and to create the short links by extracting the last 4 chars of the topic names.

I guess beauty has its price...

-- TimotheLitt - 28 Jun 2011

"this year + 1" - can done without SSP using (trunk-only):

%QUERY{"%SERVERTIME{"$year"}% + 1"}%

Test: 2012

QuerySearch only has a fraction of the operators which SpreadSheetPlugin provides, so you won't always find what you want. But the basics are there, which is usually enough.

I'm loathe to changing the SSP code, because honestly I avoid using it. Better leave this to some other brave soul who has time to thoroughly use & test the change (I note there aren't (m)any? tests for CALC's obscure rendering behaviour).

-- PaulHarvey - 29 Jun 2011

I think that this can be marked closed for 1.2. %CALCULATE macro is now enabled. That plus Timothe's backslash find should be enough to mark this fixed.

-- GeorgeClark - 04 Jan 2015

Commenting is disabled while not logged in