From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "J.P." Newsgroups: gmane.emacs.bugs Subject: bug#51342: 29.0.50; remove non-CAPs from rcirc capability list Date: Sun, 14 Nov 2021 15:07:14 -0800 Message-ID: <877ddaxrod.fsf@neverwas.me> References: <87o87gzjpd.fsf@neverwas.me> <878ryiwxf4.fsf@posteo.net> <87r1caseo5.fsf@neverwas.me> <87fsryehfx.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2980"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.60 (gnu/linux) Cc: 51342@debbugs.gnu.org To: Philip Kaludercic Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Nov 15 00:08:17 2021 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 1mmObg-0000aE-Qm for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 15 Nov 2021 00:08:17 +0100 Original-Received: from localhost ([::1]:34728 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mmObf-0006kV-Fk for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 14 Nov 2021 18:08:15 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:50608) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mmObS-0006k1-Ex for bug-gnu-emacs@gnu.org; Sun, 14 Nov 2021 18:08:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40436) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mmObS-0000nt-73 for bug-gnu-emacs@gnu.org; Sun, 14 Nov 2021 18:08:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mmObR-00055K-Vt for bug-gnu-emacs@gnu.org; Sun, 14 Nov 2021 18:08:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "J.P." Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 14 Nov 2021 23:08:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 51342 X-GNU-PR-Package: emacs X-Debbugs-Original-Cc: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.163693124419490 (code B ref -1); Sun, 14 Nov 2021 23:08:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 14 Nov 2021 23:07:24 +0000 Original-Received: from localhost ([127.0.0.1]:51982 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mmOap-00054I-Sj for submit@debbugs.gnu.org; Sun, 14 Nov 2021 18:07:24 -0500 Original-Received: from lists.gnu.org ([209.51.188.17]:36342) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mmOao-00054A-2g for submit@debbugs.gnu.org; Sun, 14 Nov 2021 18:07:22 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:50368) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mmOan-0006f8-VG for bug-gnu-emacs@gnu.org; Sun, 14 Nov 2021 18:07:21 -0500 Original-Received: from mail-108-mta190.mxroute.com ([136.175.108.190]:41813) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mmOal-0000jH-Ro for bug-gnu-emacs@gnu.org; Sun, 14 Nov 2021 18:07:21 -0500 Original-Received: from filter004.mxroute.com ([149.28.56.236] filter004.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta190.mxroute.com (ZoneMTA) with ESMTPSA id 17d20b4737f000177f.001 for (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Sun, 14 Nov 2021 23:07:16 +0000 X-Zone-Loop: cfaaa002300a91b249880cc7699384ade3ec3ad2788c X-Originating-IP: [149.28.56.236] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=neverwas.me ; s=x; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=f8yRl2dn4Pw/71XoaDVQZECRpVgr/nF/L9lqcV8WWvg=; b=Q0ayYGP6V8l7fD2D9WXV0qOp/W kOLPRCYKpsNN/SgmkVwh6FzhOg7E3kH3B7BkoIlumTaqM2t+2XTpihmCQrpMtDUVTZ2VcpuNI3y+e 5qveKvDCZPca4RBttZBEN4bIY4uB+38TJfQWIUKjNjUc2tgiQWGcXkvXMQlVnhfFArsX319FyiBjA 2ZtJqEu32vicNYPhLuxj/6dxjVhaTF3q6ug0/7jWRRiIQRlYvXX4Xdx6EdbUwhriwLnR86kYxJ0Ml OGpmW0PMPNik1R8QBgIUxxlkkq8a7DeeD1Bu45wypvFK1gTvmGXqRRhutE+An8dUpQHxbBQITtW5G bMoy/XzQ==; In-Reply-To: <87fsryehfx.fsf@posteo.net> (Philip Kaludercic's message of "Sun, 14 Nov 2021 18:10:58 +0000") X-AuthUser: masked@neverwas.me X-Zone-Spam-Resolution: no action X-Zone-Spam-Status: No, score=-0.1, required=15, tests=[ARC_NA=0, RCPT_COUNT_TWO=0, FROM_HAS_DN=0, TO_DN_SOME=0, MIME_GOOD=-0.1, FROM_EQ_ENVFROM=0, MIME_TRACE=0, RCVD_COUNT_ZERO=0, NEURAL_SPAM=0, MID_RHS_MATCH_FROM=0] Received-SPF: pass client-ip=136.175.108.190; envelope-from=jp@neverwas.me; helo=mail-108-mta190.mxroute.com X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action 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" Xref: news.gmane.io gmane.emacs.bugs:220018 Archived-At: Philip Kaludercic writes: >> Standard replies are quite mysterious. From what I can gather: > > [...] > > I understand the issue, but am still hesitant. If this is vague, then > it seems better to err on the side of safety What's mysterious and vague isn't the existence of a capability called standard-replies. No such capability currently exists. As mentioned in my last reply (not sure if you saw that one), the closest thing is inspircd.org/standard-replies. Hope that makes sense. > Or are there any real downsides to being more explicit? No downsides at present because you request one cap per line. And you have no interdependent caps as yet. So long as both remain true, there's nothing to worry about. And rcirc doesn't make you accrue flood debt, so early messages (even spurious ones) don't cost extra. In ERC's case, we *do* have to worry because we implement 302 and have multiple dependencies. If any one gets NAK'd, there goes the ball game. There's also some undefined behavior [1] that can turn connection registration into a bit of a limbo without additional planning (should you ever decide to go that route). Thanks. [1] https://github.com/ircv3/ircv3-specifications/pull/400#issuecomment-579063998