From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Semyonov via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#64202: [PATCH] Gnus: Add back end for Atom feeds (nnatom) Date: Wed, 21 Jun 2023 12:50:48 +0300 Message-ID: <87r0q5m9dz.fsf@dsemy.com> References: <87v8fhmgvw.fsf@dsemy.com> Reply-To: Daniel Semyonov Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37949"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: 64202@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jun 21 11:53:23 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qBuWf-0009eN-DK for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 21 Jun 2023 11:53:21 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qBuWP-0000RI-C3; Wed, 21 Jun 2023 05:53:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qBuWM-0000Qo-S3 for bug-gnu-emacs@gnu.org; Wed, 21 Jun 2023 05:53:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qBuWM-0005Oy-JQ for bug-gnu-emacs@gnu.org; Wed, 21 Jun 2023 05:53:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qBuWM-0004j1-Fh for bug-gnu-emacs@gnu.org; Wed, 21 Jun 2023 05:53:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Semyonov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 21 Jun 2023 09:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64202 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 64202-submit@debbugs.gnu.org id=B64202.168734117418143 (code B ref 64202); Wed, 21 Jun 2023 09:53:02 +0000 Original-Received: (at 64202) by debbugs.gnu.org; 21 Jun 2023 09:52:54 +0000 Original-Received: from localhost ([127.0.0.1]:60683 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qBuWE-0004iY-4h for submit@debbugs.gnu.org; Wed, 21 Jun 2023 05:52:54 -0400 Original-Received: from dsemy.com ([46.23.89.208]:35203) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qBuWA-0004iE-2g for 64202@debbugs.gnu.org; Wed, 21 Jun 2023 05:52:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=dkim; bh=/nP0HlV6tECzv 7/IfSoaQBTwF+The7V2coyRtYcOlsM=; h=date:references:in-reply-to: subject:to:from; d=dsemy.com; b=U3DVx9gRzmx6N5rBb6KbVfkcap+0crjnE5x7ws pqKwgYOZi2mNtOOPNulFeiEelo7vu0AtnzsCJHq44JniWhctweX4Qi4sVCEV/b/rxNbLBN aNTnR9ciJLMn2+dCTKIWv2PdGc3G3HQGtWoKpJeR/KsAAYUHQaFbjsYNJHjL1yWSGQ+PWW MG/JqZho8Vf/iTPKJRpre/dAiVAV1hmw9tJHZSsoAnnT4Abw/4bw2mdcuj9JW4zxycfu75 bpYOl9JGn83FQQjdXdjzZ+aEI9zw6uEJQoETkrncAPMpDXcFsm2sz/jHz+4E4suWPPt8mu hJSB4pqTO04nWtejo2i1+60A== Original-Received: from coldharbour.home.arpa (bzq-109-64-87-185.red.bezeqint.net [109.64.87.185]) by dsemy.com (OpenSMTPD) with ESMTPSA id 2c005eb1 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for <64202@debbugs.gnu.org>; Wed, 21 Jun 2023 11:52:43 +0200 (CEST) Original-Received: from localhost (coldharbour.home.arpa [local]) by coldharbour.home.arpa (OpenSMTPD) with ESMTPA id 49483744 for <64202@debbugs.gnu.org>; Wed, 21 Jun 2023 09:50:48 +0000 (UTC) In-Reply-To: <87v8fhmgvw.fsf@dsemy.com> (Daniel Semyonov's message of "Wed, 21 Jun 2023 10:08:51 +0300") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:263794 Archived-At: --=-=-= Content-Type: text/plain I realize I never wrote down much about the internals of the back end in detail, so here are some notes: - This backend supports all features of Gnus which (I think) make sense. - It is separated into three main parts - a set of parsing functions specific to Atom, a fairly generic implementation of server data storage (since most Atom feeds only contain the few most recent articles), and a Gnus back end interface which uses the former two parts to get information for Gnus. The intention is to allow creating inheriting back ends for different types of feeds by only changing the first part (and all of its functions are therefore stored in server variables). This also means a user can customize the parser by customizing the select method, which is pretty cool. - The function responsible for printing the content of each part is also stored in a server variable ('nnatom-print-content-function). This means that 'nnatom-read-links-function' can return any Lisp object and 'nnatom-read-parts-function' can return any Lisp object as its car and any Lisp object in its cdr (a list) with a custom value of 'nnatom-print-content-function'. The reason it is customizable is that Atom feeds only support plain text and (X)HTML feeds, and they already require some extra work to display nicely; I suspect if other web feed formats support other types of content they would also require something like that. And of course it can also be customized through the select method. - A macro is provided which eliminates most of the boilerplate code required to define an inheriting back end. I've also attached a simple inheriting back end for youtube channel feeds - they are very slightly different from normal Atom feeds so it's a good way to know whether issues come from the back end itself or from the inheritance mechanism. Regards, Daniel --=-=-= Content-Type: application/emacs-lisp Content-Disposition: inline; filename=nnyt.el Content-Transfer-Encoding: quoted-printable Content-Description: nnyt ;;; nnyt.el --- yt backend for Gnus -*- lexical-binding: t -*- ;; Copyright (C) 2023 Daniel Semyonov. ;; Author: Daniel Semyonov ;; Package-Version: 0.1 ;; This file is not part of GNU Emacs. ;; nnyt is free software: you can redistribute it and/or modify ;; it under the terms of the GNU General Public License as published by ;; the Free Software Foundation, either version 3 of the License, or ;; (at your option) any later version. ;; nnyt is distributed in the hope that it will be useful, ;; but WITHOUT ANY WARRANTY; without even the implied warranty of ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ;; GNU General Public License for more details. ;; You should have received a copy of the GNU General Public License ;; along with nnyt. If not, see . ;;; Commentary: ;;; Code: (require 'nnatom) (nnoo-declare nnyt nnatom) (nnatom-define-basic-backend-interface nnyt) ;;;; YouTube feed parser: ;; All channels have the same prefix, so an address can be just a channel i= d. (defvoo nnyt-read-channel-function (lambda (feed group) (nnatom--read-feed (concat "youtube.com/feeds/videos.xml?channel_id=3D" feed) group)) nil nnatom-read-feed-function) ;; YouTube feeds don't contain a summary or content, only a "description". (defvoo nnyt-read-description-function (lambda (article) `(,(nnatom--read-part (dom-text (if-let ((d (dom-child-by-tag article 'group))) (dom-child-by-tag d 'description) (dom-child-by-tag (dom-child-by-tag article 'media:gr= oup) 'media:description))) "plain" t))) nil nnatom-read-parts-function) (gnus-declare-backend (symbol-name nnyt-backend) 'address) (provide 'nnyt) ;;; nnyt.el ends here --=-=-=--