#foswiki 2017-07-18,Tue

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)

WhoWhatWhen
***geetar has left [00:15]
......................... (idle for 2h4mn)
ChanServ sets mode: +o gac410 [02:19]
....................................... (idle for 3h13mn)
ChanServ sets mode: +o Lynnwood [05:32]
............... (idle for 1h12mn)
ChanServ sets mode: +o MichaelDaum [06:44]
..................................................................... (idle for 5h41mn)
ChanServ sets mode: +o gac410 [12:25]
................... (idle for 1h32mn)
LynnwoodHey gac410 - I see you worked on CalendarPlugin back in 2015. [13:57]
As some point in the last two releases of Calendar, a feature was lost that had just been added in release 2.00: support for macro expansions to provide the event lists. This was kind of a key feature for me and I'm hoping I can figure out how to get it back.
This allowed for generating the list of events from a SEARCH which in turn provided for storing events in discrete topics/data forms.
I have a couple of applications out there that depended on this.
In another matter related to plugins, is there some general info somewhere regarding the general issue of "Unescaped left brace in regex"? Is the fix more of less the same everywhere it shows up or does it require special treatment in each case?
Maybe i can figure that out but looking at some of the plugins that have been fixed...
oh.. i see... it looks like it's escaping the curly brackets in macros.
that looks pretty straight forward.
And the error messages that get generated even tell us where to find them.
[14:10]
I just edited Tasks.Component so that it doesn't pick up tasks for plugins whose names include other plugin names. For example the "CalendarPlugin" page was displaying tasks for "FullCalendarPlugin".
Maybe that's a rare case...
or even the only case... lol
[14:29]
.... (idle for 16mn)
gac410Hi Lynnwood yes the braces fix is to change { to \{ except where it's active in the regex {1,3} for ex. And I usually also escape the } so that they are clearly matching, though only the { actually needs the escape.
Only complicated one is when a macro or code "constructs" the regex, Those can be a bear to find.
Re the Tasks.Component. Half the time I agree with your change, But there are also good examples where the wider search is helpful as well.
Not that I can think of any.
I don't think I would have intentionally removed a feature from the plugin. But maybe my change to the way it used INCLUDE to pick up events broke something. Item10135
[14:46]
FoswikiBothttps://foswiki.org/Tasks/Item10135 [ Item10135: CALENDAR macro breaks when preceded by STARTINCLUDE and STOPINCLUDE macros ] [14:51]
gac410Ah ha... yes it did break that Lynnwood_
The %INCLUDE used expandCommonVariables to process the include, which also would have expanded any SEARCH macros.
Probably change line 488 in this diff to read $text .= Foswiki::Func::expandCommonVariables($evText, $evTopic, $evWeb);
https://github.com/foswiki/CalendarPlugin/commit/7ffdc143a313
[14:52]
FoswikiBothttps://trunk.foswiki.org/System/PerlDoc?module=Foswiki::Func [14:57]
gac410or maybe even $text .= Foswiki::Func::expandCommonVariables($evText); leave off evWeb and evTopic to use the current topic's settings.
Ah there is one risk there. If expandCommonVariables expands a %CALENDAR% while processing the %CALENDAR% macro, that can cause evil things to happen if it ends up causing a loop.
[14:58]
Lynnwoodthat makes sense. I
bbib
[15:07]
gac410ugh. So looking back over history, Crawford did a complete restructuring in his changes, splitting into a Core.pm module. And in the process removed some recursive code for expanding the includes, changing it to the simple expansions.
And letting Foswiki do the recursive part as part of expandCommonVariables.
My fix is questionable. Maybe I should have just documented that events need to be part of a STARTINCLUDE / STOPINCLUDE if part of the topic.
[15:08]
Lynnwood: The real solution is to revert my commit https://github.com/foswiki/CalendarPlugin/commit/7ffdc143a313 and update the documentation to state that: If the topic contains "STARTINCLUDE or STARTSECTION type=include, then events must be part of that section.

Please open a task and I'll get it fixed.
[15:16]
***ChanServ sets mode: +o cdot [15:18]
gac410Hey cdot ... looks like my change to CalendarPlugin back in 2015 completely broke your use of INCLUDE to pick up events :( I need to revert my Fix to Item10135, and instead document that events are only read from STARTINCLUDE sections. [15:30]
FoswikiBothttps://foswiki.org/Tasks/Item10135 [ Item10135: CALENDAR macro breaks when preceded by STARTINCLUDE and STOPINCLUDE macros ] [15:30]
foswiki_irc9Hello, I created a topic with few edit-tables, which needs to be filled with variable data. I will be using the same tables during my work several times for which I would like to use it as a template. could you please help me in this regard ? [15:30]
gac410This use of INCLUDE was not documented and I unfortunately removed it by not understanding the side effects.
foswiki_irc9: If you create a topic named: SomeTopicTemplate ... then when you create a new topic, you should be able to pick it as the template topic
See Foswiki:System/TemplateTopics
[15:31]
FoswikiBothttps://foswiki.org/System/TemplateTopics [ TemplateTopics ] [15:33]
............ (idle for 59mn)
foswiki_irc9That worked now. Thank you [16:32]
LynnwoodHey @gac410 - I'll post a task. [16:40]
gac410thanks. I'm still trying to decide if revert, and document the SECTION restriction is the correct fix, or just add the expandCommonVariables [16:40]
cdotgac410: CalendarPlugin? Is that one of mine? I forget. So many years, so much code :-( [16:43]
gac410No, it's a feel-free-to-modify that you fixed, and i fixed and broke your fix :(
I think it's best to revert my fix, and just document that if there is a STARTINCLUDE type section, then events are only read from that section.
I could add a "expandCommonVariables call to my change. INCLUDE and SEARCH would then be supported, but events could appear anywhere in the base topic even if there is a STARTINCLUDE section
anyway my fix that broke your fix was https://github.com/foswiki/CalendarPlugin/commit/7ffdc143a313
[16:44]
LynnwoodItem14440 [16:48]
FoswikiBothttps://foswiki.org/Tasks/Item14440 [ Item14440: Item10135 broke macro expansion to provide the event lists ] [16:48]
gac410Lynnwood: You could see if $text .= Foswiki::Func::expandCommonVariables($evText); is sufficient, or if stepping all the way back to CDot's version would be better. [16:49]
FoswikiBothttps://trunk.foswiki.org/System/PerlDoc?module=Foswiki::Func [16:49]
LynnwoodSure, i've give it a try. [16:50]
gac410My suggested change would process the complete named topics without any SECTION restriction, but if they then use %INCLUDE% for further nesting, that would fall under the SECTION restriction. [16:50]
Lynnwoodgac410 - worked like a charm (at least as far as my use case was concerned)
it's a good sign though because I did all kinds of crazy processing to generate the list - including SEARCH, plus calculations with SSP.
[16:58]
gac410okay, so the only question then is, is there an advantage to INCLUDING the topics named in topic=... and restricting events to the STARTINCLUDE section?
A) for each topic=...,. expandCommon(%INCLUDE) vs B) for each topic=... read topic and expandCommon()
[16:59]
LynnwoodIn my case, i didn't use a STARTINCLUDE, I just referenced the topic and had a bunch of searches there which generated lists. [17:01]
gac410I think that the latter may be less confusing for people who just put the events in the current topic. [17:01]
LynnwoodCalendarPlugin could sure use some love. I'd like to at least provide some styling for the calendar. I haven't discovered exactly why, but with NatSkin, it looses all styling. [17:05]
cdotLynnwood: isn't it replaced by some jQuery magic these days? [17:07]
Lynnwoodthe styling for the Calendar? [17:08]
cdotthe whole calendar. [17:08]
Lynnwoodor the calendar in general
perhaps should be...
[17:08]
gac410I think that is FullCalenderPlugin, and it's broken iirc. I tried to fix it but iirc it was rather challenging. beyond me. [17:08]
LynnwoodBut i still need ability to generate list of event (in all the variations of repeating, etc). Guess I could review avaiable calendars and look at event syntax.
I did this a few years back... and came back to CalendarPlugin.
[17:09]
cdotcdot uses CalDAV, not touched calendars inside Foswiki for a long while [17:11]
LynnwoodHere's the core feature that I wanted/implemented that I couldn't find elsewhere: _relative_ dates. I created a garden planting calendar that includes lots of events relative to other events - for example relative to freeze dates, or planting.
http://middleforkhome.us/Almanac/WebHome
[17:21]
..................... (idle for 1h44mn)
***deep-book-gk_ has left [19:06]

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)