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#74857: 30.0.92; Gnus nnatom: url protocol Date: Sun, 22 Dec 2024 23:12:31 +0200 Message-ID: <877c7ra0cg.fsf@dsemy.com> References: <875xnn9z29.fsf@librehacker.com> <865xnd8j12.fsf@gnu.org> <87zfkpq9ay.fsf@dsemy.com> Reply-To: Daniel Semyonov Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5384"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Christopher Howard , Eli Zaretskii , 74857@debbugs.gnu.org To: Stefan Kangas Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Dec 22 22:14:20 2024 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 1tPTHH-0001E6-Dg for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 22 Dec 2024 22:14:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tPTH1-0005zn-QP; Sun, 22 Dec 2024 16:14:03 -0500 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 1tPTH0-0005zL-FX for bug-gnu-emacs@gnu.org; Sun, 22 Dec 2024 16:14:02 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tPTH0-0004HX-6q for bug-gnu-emacs@gnu.org; Sun, 22 Dec 2024 16:14:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=EASSJWjzzVfMsVGdNxwWcmD2BPvL7Xw3kzPZsxXZRcs=; b=VprCMUJ0ghCEWd0kVKPthxiIsKRTmsfDutcviwzDqaHifsSTbL1aJJreumAm7q8HMtH+yFF7VBIxS4imUGohWpgH/aDC6YJkk0qEZls6onjjQMcs7yUF/s/CKGIybjNQdNUqlDB0kWbQQqG3bbKKnZXWDW3tyAZZ6aSevWn4styVODar4s5lZmpZ0cK1Q6HJ0PoRB1f95Y9m5+fuwiSIVBzqJN9hSmhfaaxXcDDWOhTscZ4qDrXxoDhyuNXq5AGLe4099NxDb0l/NgxGeONXCjc2IRfmGOLKVgeG67squf6v64rCzX+yjlroTaNC6wN1oTSQqmeqhuqC9YQCPMo0MQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tPTH0-0001iz-18 for bug-gnu-emacs@gnu.org; Sun, 22 Dec 2024 16:14:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Semyonov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 22 Dec 2024 21:14:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74857 X-GNU-PR-Package: emacs Original-Received: via spool by 74857-submit@debbugs.gnu.org id=B74857.17349020346606 (code B ref 74857); Sun, 22 Dec 2024 21:14:01 +0000 Original-Received: (at 74857) by debbugs.gnu.org; 22 Dec 2024 21:13:54 +0000 Original-Received: from localhost ([127.0.0.1]:52157 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tPTGs-0001iT-BH for submit@debbugs.gnu.org; Sun, 22 Dec 2024 16:13:54 -0500 Original-Received: from dsemy.com ([46.23.89.208]:1940) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tPTGp-0001iG-Po for 74857@debbugs.gnu.org; Sun, 22 Dec 2024 16:13:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=dkim; bh=EASSJWjzzVfMs VGdNxwWcmD2BPvL7Xw3kzPZsxXZRcs=; h=date:references:in-reply-to: subject:cc:to:from; d=dsemy.com; b=KEMP+Sg13goW+g/KDmMVSwmYIcizbSgvk8/ /pIH7giUf5LNDLoIteFtsyZrvea/QaFPdnw1BZQCwpNXmtQVmrlOnw3rV02Y8XTS2RUgll jg1q//3MYAc/NUzok37QcpDm3N8W4I2ZSD+AdxYy3nYRcvCCvioeNEWRAyHvOGTo+eTtqJ 2YpiSpHH3O72Iz4KmkZLx4TiWNZfPXeeg8HJ6QIdeC5v++xYghrvA1alQX3cT9c1e9u+8A gPGMgxD7bFcE6TQGKebwCBN2Y9+stHoXppT7zQDt+VG6n6o51psY8inhKANjlM/TNwLWqa D2tOWKKtAlsvE5kXjMEv6HRVPSg== Original-Received: from coldharbour (204.134.hqserv.co.il [185.191.204.134]) by dsemy.com (OpenSMTPD) with ESMTPSA id 73bcbd79 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sun, 22 Dec 2024 22:13:38 +0100 (CET) In-Reply-To: (Stefan Kangas's message of "Sun, 22 Dec 2024 01:29:42 +0000") 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:297630 Archived-At: >>>>> Stefan Kangas writes: > Daniel Semyonov via "Bug reports for GNU Emacs, the Swiss army knife of > text editors" writes: >> This is a known issue (also noted in the manual), though the message >> returned should be more descriptive. >> >> The returned message is emitted by Gnus when it fails to get info for >> the server from the backend, and should use the value of >> 'backend-status-string' ('nnatom-status-string' in this case); this >> works on a normal session on my end (returning a message set in >> 'nnatom--read-feed'), but fails with emacs -Q, also returning "Couldn't >> request list: nil". >> I half suspect this is a bug with Gnus trying to read the status string >> of the wrong server (and not a bug in nnatom), but I'll look into it. >> >> As for why it isn't allowed in the first place, Gnus unfortunately >> breaks when ":" is used in server addresses due to regular expressions >> used in various internal functions, though I don't remember the details. > Does nnatom use http or https by default in these situations? nnatom always uses https, feeds available only over http are not supported at all currently (unless they are downloaded separately, and added to nnatom as a file instead of a URL). This is something I wanted to address at some point but honestly forgot about it, though I'm not sure how important it is TBH; adding a server variable controlling this would be fairly easy to do, I think. In any case I still haven't had time to look into the issue with the wrong returned message, I'll look into both issues in a few days (hopefully). Daniel