Desktop: Add `enex` to `html` export #1795
Features introduced in this PR
Adds a new ENEX – Evernote Export File (as HTML) importer (as discussed in the forum):
It takes the raw XML in the
Refactored in this PR
I'd love your thoughts on the following:
I'd love to also add an importer that uses the HTML importer if it's a clipping and converts to Markdown if it's a user-made note. I see two ways of doing this:
Option 2 seems more elegant to me, plus it gives us space to offer a bit more information about the consequences of the options, but it does deviate from the current import model more.
Aug 11, 2019
Thanks for the pull request @devonzuegel and sorry for the delay in replying. I was in vacation in August and didn't have time to really look into the code till now.
It's fine as it is as the feature is quite self contained.
We always squash and merge so multiple commits are fine.
The tests you've added are fine I think. As for the UI, we currently don't have any way to test it unfortunately.
I don't quite understand the need for HTML cleaning. The Evernote HTML should already be valid, shouldn't it?
I agree with that, we can leave it as you did.
Thanks for clarifying and indeed it makes sense, so we can keep this html cleaning module.
In a recent commit, I've also added html-minifier, mostly to reduce the size of imported clipped pages. Do you think you can use this one to clean the Evernote notes? I guess the purpose of these modules is a bit different though, so if not possible, it's fine to keep the clean-html module.
Also when creating these notes, I think it would be better to set the
From a look through the docs, the minifier seems only to collapse the HTML, rather than displaying it as a nicely-indented, pretty-formatted output. Unless I'm missing some function that reverse-minifies, in which case I'm happy to use it!
Oh that sounds great! Can you point me to how to do it? Since the importer just receives the final string, I'm not sure where to set he
Right I wasn't sure, but indeed they don't really do the same thing, so let's keep the clean-html module you've added then.
Also is it possible to add a comment to explain what
I've tested and it's all looking good. HTML and resources are imported fine and the HTML mode also seems to be working.
There's just the package-lock conflict that needs to be fixed. You could just delete the file actually and recreate it by running
The steps to build a release is on the Travis file: https://github.com/laurent22/joplin/blob/master/.travis.yml#L55 Normally if you run these commands you should get the macOS package in the "dist" folder.
@devonzuegel, unfortunately I had to temporarily revert this PR due to a few issues. I tried to fix some of them yesterday and I thought I was done, but today I found something else and it's harder to fix. I don't want this to block the release of the app, so that's why I'm taking it out but happy to merge it back again once it's fixed.
The first issue was that the app normally relies on auto-detection of the format based on the extension, but this capability was removed with the addition of
The second issue is a slightly bigger one and I haven't tested everything but in particular the feature to import MD directory is broken on the desktop app (and probably CLI). This is also due to
I feel the simplest way would be to go back to using the
Sorry about that, I wish I had spotted all this before. I guess one issue is that we don't have any unit testing for the front-end so it's easy to miss these issues.