Fix "incompatible character encodings" error.

[fabacab]

Certain input from iCalendar-formatted files resulted in an uncaught "incompatible character encodings" exception when requesting the simple_html_description of the event. Jekyll build failures result.

For example, if a user enters emoji into a Google Calendar description field, the .ics file produced by Google Calendar will be in UTF-8. If the system running jekyll build does not set UTF-8 to be the default character encoding, the "incompatible character encodings" error will be triggered, failing the build.

This commit (lazily?) addresses the issue by forcing the cloned description variable to the same encoding as the url string is encoded in, which is set to "UTF-8" by description_urls, earlier.

[rickychilcott]

Thanks for the PR! Merging and will cut another release.

[rickychilcott]

Version 1.0.6 has been released

[rickychilcott]

Thanks @meitar

[fabacab]

Sure, glad to help.

Actually, if you don't mind my pestering you for a moment longer, I've been having a number of similar incompatible encoding errors, but I'm feeling a little out of my depth with Ruby and I worry it might just be a PEBKAC issue.

At the moment, I'm just having a lot of trouble installing the Gem. What I originally did was simply add the Gem (but, from RubyGems.org) to my existing Gemfile and then ran another bundle install. That pulled in version 1.0.4 of the jekyll-ical-tag Gem and worked without an issue.

Then I wrote the above patch. But since I've been having more trouble, I decided to blow away my vendor/bundle directory and re-install Jekyll. However, now I'm having other problems I'm feeling stumped by and would love any assistance you can offer.

My original Gemfile looks like this:

$ cat Gemfile
source 'https://rubygems.org'
gem 'github-pages', group: :jekyll_plugins
gem 'jekyll-menus', group: :jekyll_plugins

That's the whole thing. From a clean install (no existing vendor/bundle directory in which Jekyll is already installed), if I add your recommended installation line to my Gemfile:

$ cat << EOF >> Gemfile
> gem 'jekyll-ical-tag', git: "https://github.com/Rakefire/jekyll-ical-tag.git"
> ^D

then I get this error upon attempting a bundle install:

$ bundle install
Fetching https://github.com/Rakefire/jekyll-ical-tag.git

[!] There was an error while loading `jekyll-ical-tag.gemspec`: cannot load such file -- jekyll
Does it try to require a relative path? That's been removed in Ruby 1.9. Bundler cannot continue.

 #  from /Users/myuser/src/my-jekyll-project/vendor/bundle/ruby/2.6.0/bundler/gems/jekyll-ical-tag-e606556550b1/jekyll-ical-tag.gemspec:6
 #  -------------------------------------------
 #  
 >  require 'jekyll'
 #  require "jekyll-ical-tag/version"
 #  -------------------------------------------

So, I guess, my question at the moment, am I doing something stupid? Am I failing to understanding something basic about Bundler that has eluded me for years? Why does this error not present when I simply specify the gem without its git parameter in my Gemfile? I get that the error is pointing at requiring Jekyll, but this dependency should already be satisfied by the github-pages Gem added earlier.

Sooo…halp?

[fabacab]

Okay, I think I may have a working theory as to what's happening. This excerpt from the Bundler docs…

When attempting to locate a gem to satisfy a gem requirement, bundler uses the following priority order:

1. The source explicitly attached to the gem (using :source, :path, or :git)
2. For implicit gems (dependencies of explicit gems), any source, git, or path repository declared on the parent. This results in bundler prioritizing the ActiveSupport gem from the Rails git repository over ones from rubygems.org
3. The sources specified via global source lines, searching each source in your Gemfile from last added to first added.

…seems to suggest that what's happening is that, when my Gemfile overrides the source for the jekyll-ical-tag Gem by adding a :git keyword argument to the gem method call as your README indicates that we should do, Bundler interprets this to mean that it should use this same Git source (i.e., your GitHub repository) to find the Gems that are required for satisfying this same Gem. This means Bundler searches your GitHub repository to see if it can find the jekyll Gem. Naturally, this fails.

I have a functional workaround now, but it involves editing the .gemspec file for this Gem in my own fork in three places (removing both require lines and hardcoding the spec.version attribute value). I have to believe it's my inexperience with Ruby packaging, but this feels like a really kludgy way to fork a Gem. Am I wrong? Is there a Ruby best practice that I'm missing?

Anyways, now that I have a working fork, I can go ahead and finish my integration testing. You'll find another PR soon!

Thanks again for a great little Jekyll plugin.