Look for epic editor in epiceditor/js

ok, indeed, the tarball contains: ./EpicEditor-v0.1.1.1/epiceditor/js/*

So this change proposal is in line with how we're dealing with other editors.

The only problem I see is that the current path has been released already... what about people who installed it already?

Note that I'd also be fine with doing this change... since EpicEditor was introduced only recently, I doubt that there are actually many users.

Let's see what @TwoD thinks.

Also note the download link for epic editor is wrong. Rerolled #2

pd.
@fabstor FYI you can tell drush make (5.x) to pick a subdir:

libraries[epiceditor][download][type] = get
libraries[epiceditor][download][url] = http://oscargodson.github.com/EpicEditor/docs/downloads/EpicEditor-v0.1.1.1.zip
libraries[epiceditor][download][subtree] = EpicEditor-v0.1.1.1/epiceditor/js

fixing a typo

Patch works for me using Drush 4.6. I did a manual code review and the changes seem fair enough.

I wouldn't be surprised if the maintainer of epiceditor changes the structure of the zip file sometime in the future, but for now this simple change helps a lot :)

I've already committed an URL update so we can skip that from the patch. (Set both to point to epiceditor.com to avoid directly linking to the package and having it break on every release.)

The version number does not need updating since it specifies the lowest library version the JS integration file is compatible with.

I think I would actually prefer if people used the libraries[epiceditor][download][subtree] = EpicEditor-v0.1.1.1/epiceditor/js method described in #6 for Drush Make. That's only available in 5.x though so I think I'm OK with this change too.

The file structure is at least the same for EpicEditor version 0.2.0, but it became quite apparent the developer is on a Mac. Pretty much every zip file I get from Mac users also include a __MACOSX folder in the root and .DS_Store files here and there (a pain in the ass to remove every time). I can't understand why developers don't care more about packaging their releases consistently.

Wysiwyg's currently not designed to look for libraries or variants of them with different path prefixes. If we in a future version merged together all the callbacks which gather information about the package that would be a lot easier to handle (and cache).
Until then, I suppose the best we can do is make these path changes.

UPDATE: It is possible to override the 'library path' and 'editor path' editor metadata keys using the 'versions' key. I plan to use this to support TinyMCE 4 which also has a new folder structure. The kludge is a bit more complex logic in the version callback since it has to take all the possible path prefixes into consideration when looking for files.

EpicEditor switched back to using the EpicEditor-v0.2.2/js/epiceditor.js structure after unpacking. I think the other structure may have been a mistake in the release packaging.
We'll still have to rename the main folder because of the version number in the name for now. Maybe we can fix that later, but Wysiwyg isn't designed to scan through all folders in sites/[all|default|sitename]/libraries/* and its likes because it would currently have to do this on every page request where an editor will be loaded.

Closing this for now.