Closed clarete closed 5 years ago
The format looks rather similar, so I don't see why not.
I have a few reservations, but they're not significant enough to oppose the idea:
hackernews
won't reflect its support for other aggregators. We'll either have to live with this misnomer, or rename the package altogether. This issue will also be seen in the namespace and naming of user options, etc.As I said, as far as I'm concerned none of these issues are stoppers. But they definitely constitute sufficient motivation to start a new news reader project which supports arbitrary APIs, rather than only a particular protocol like RSS, Atom, or NNTP. This project would provide as generic an interface to underlying backends/news sites as possible, similarly to how Gnus abstracts NNTP, IMAP, Maildir, etc. hackernews.el
could then be adapted to whatever format this new project expects of its hot-pluggable backends, and standalone hackernews.el
would be deprecated.
Another, similar approach would be to add a lobsters.el
file or similar alongside hackernews.el
. The two files could share whatever logic they have in common under the same repo, but they would be installable as separate packages, similarly to how Ivy, Swiper, and Counsel are packaged separately but live under the same roof.
The latter would probably be the quicker and easier of these two approaches, but I find the idea of the former much more interesting and challenging.
AFAICT, the only API lobste.rs has at the moment comprises the following two endpoints:
As well as a story view, e.g. https://lobste.rs/s/mbw0z5.json
Do you see any others?
See lobsters/lobsters#555.
Sorry for the slow response and thanks for such thorough answer!
That's a very interesting list of points you raised! And it's really interesting because although the first point is probably the easiest to ignore, I think it might be the most important one for me! But I think my response will cover all the points.
I think one of the reasons I didn't look for an existing news client was because I was coming back from a long pause from reading news feeds in general (I spent way too much time on that) and wanted to build a client for that specific site and it really made sense to have the package named hackernews
and it really made sense to me to have a function accessible via M-x hackernews
.
And tying back to the options you listed, there might be a way to maybe allow us to provide a generic specific from the design perspective but allow the same experience for both websites.
The suggestion I make is to publish two packages with the same content (maybe different autoloads?) but to allow people to invoke the same software for different URLs via M-x hackernews
and M-x lobsters
and install it the same way, like M-x package-install
would install either lobsters
or hackernews
just fine. What do you think? The namespace seems available!
The suggestion I make is to publish two packages with the same content (maybe different autoloads?) but to allow people to invoke the same software for different URLs via M-x hackernews and M-x lobsters and install it the same way, like M-x package-install would install either lobsters or hackernews just fine. What do you think? The namespace seems available!
SGTM. I won't have time to work on it myself any time soon, though. :/
No worries! I'll see if I can find some time to put a prototype together! Thanks a lot for the answer! <o/
Started putting something together as a separate package. Since the idea is to keep the names separate, maybe it should be a separate package all together. I'll close this issue for now, not really sure if it's of interest of anyone else either way so keeping this package clean doing just one thing sounds like a better idea for now.
This news client is rather awesome, and I wish I could use it to read news from https://lobste.rs/ as well as hackernews. Does anybody else feel like it'd be a good idea to support another feed in our humble little client?