This recipe wasn't working (at least for me), where it would
consistently fail with the following error when trying to download an
article:
```
Traceback (most recent call last):
File "calibre/utils/threadpool.py", line 100, in run
File "calibre/web/feeds/news.py", line 1186, in fetch_obfuscated_article
File "<string>", line 157, in get_obfuscated_article
File "<string>", line 142, in get_textview
File "re.py", line 201, in search
TypeError: expected string or bytes-like object
```
I believe this is because Pocket don't allow access to their
"Article View" API by default:
https://getpocket.com/developer/docs/v3/article-view
This change uses the original URL of the article, rather than the
pocket url for it (those `getpocket.com/a/read/<id>` URLs in the
browser seem to just redirect me to `getpocket.com/my-list`). I've a
feeling that the old way might have produced cleaner articles (Pocket
cleanup & then Calibre cleanup), but I've never seen it work
successfully.
We could alternatively try to convince Pocket to enable that API for
the "app" we use here (I think this usage would qualify, as it's a
"Pocket specific feature" (for Calibre)). That might require adopting
their full OAuth flow, rather than using username/password. From
reading their API docs with Calibre in mind, I think that would mean
we'd have to have a web page somewhere that the user would have to
access in their normal web browser, click a button to redirect them to
the Pocket page to authorize the Calibre app to access their Pocket
account, which would then redirect them back to our web page where
we'd instruct them to enter the access token into the "password" field
for the recipe in Calibre.
In commit e7e0aea6958b1419a5e72c85da0e0f920d36fb53, this was added with
the wrong name -- the "lrfviewer" application doesn't have a hyphenated
name, oddly enough, even though it is in fact "ebook-viewer" not
"ebookviewer".
On the other hand, it's probably not worth fixing the inconsistency,
because changing desktop filenames can be (a bit) disruptive if people
have pinned or modified them, and it's not worth it just for a stray
hyphen. Changing the actual program executable name is even less worth
it...
This was initially added in commit
efb83eb6fcd1b175e70281fc0776ca2e53422ad0 with a filler name that,
however, didn't match the usual style of desktop filenames. When the
actual desktop file was added in commit
a87092ba4f5e61aa51149c2c34880582613037f0 it didn't match the filename.
Although it was mass renamed from "tweak" to "edit" in commit
289ef5f0b9a4a87e6918744af64ff0d80f6a6c42, the word ordering was still
wrong.
As a result, application menus failed to correlate open windows to
pinned icons, or (on application menus that support it) group the
windows together.
calibre.devices.usbms.hal was added as a FreeBSD backend, but the test
exclusion only tries importing it on Linux. It does import on Linux, but
what we actually care about is that it imports on FreeBSD.
