Conversation
|
We use the I'm a little concerned about duplicate events, but my tests say it's not an issue. Needs checking... Wondering if the documentation and the implementation feel right. |
# Conflicts: # Gemfile # lib/jekyll-ical-tag/calendar_parser.rb # spec/calendar_feed_coordinator_spec.rb
# Conflicts: # lib/jekyll-ical-tag/calendar_parser.rb
|
@whatnotery - I was able to get your commit in (and updated the specs to reflect dropping the original event) in 1fe0464. Can you try this branch once more and make sure it works for your needs? BTW, do you think the documentation is clear? |
|
Actually @whatnotery, now that I think about it dropping the first occurrence might be wrong. Imagine a recurring event defined 2 years ago. Asking for the occurrences between today and next year would give you all of those occurrence, none of which should be dropped. I’ll need to work out this I tests tomorrow/this weekend. |
|
This commit resolves the issue as far as I can tell from the testing I did in my dummy applications. It doesn't do the drop(1) so events down the line aren't dropped but it utilizes the first occurrence from .occurrences_between instead from the initial parse |
rickychilcott
force-pushed
the
feature/recurring-events
branch
from
311acf2 to
ca653df
Compare
|
OK. Maybe i see how 2526d40 would do it. Every event (even if it isn't a recurring event) will have "occurrences" I think that could would negatively interact with other filters though because of how @recurring_start_date and @recurring_end_date would limit. I think I like my solution, but I'm not 100% sure it's right. Thanks for working through this with me. |
|
Yeah of course! Thanks for being such an awesome maintainer! It's crazy to me to have made a feature request and to have the feature built by the maintainer less than two days later. Thank you so much. I'll test it out later this evening or tomorrow |
|
Available in version 1.6.0. Thanks @whatnotery! |
2 participants
Address #45