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#49860: 28.0.50; add IRCv3 building blocks to ERC Date: Tue, 16 Jul 2024 20:17:38 -0700 Message-ID: <874j8oiu5p.fsf__2414.91661160893$1721186314$gmane$org@neverwas.me> References: <87pmuuvx3p.fsf@neverwas.me> <87h6cp6dz7.fsf@neverwas.me> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27339"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-erc@gnu.org, 49860@debbugs.gnu.org To: =?UTF-8?Q?Bj=C3=B6rn?= Bidar Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jul 17 05:18:26 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 1sTvBR-0006sV-6F for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 17 Jul 2024 05:18:25 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sTvB3-0006qM-FH; Tue, 16 Jul 2024 23:18:01 -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 1sTvB1-0006oF-8P for bug-gnu-emacs@gnu.org; Tue, 16 Jul 2024 23:17:59 -0400 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 1sTvB0-0008Fq-WF for bug-gnu-emacs@gnu.org; Tue, 16 Jul 2024 23:17:59 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sTvB3-00086w-Ld for bug-gnu-emacs@gnu.org; Tue, 16 Jul 2024 23:18:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "J.P." Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 17 Jul 2024 03:18:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49860 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 49860-submit@debbugs.gnu.org id=B49860.172118627231162 (code B ref 49860); Wed, 17 Jul 2024 03:18:01 +0000 Original-Received: (at 49860) by debbugs.gnu.org; 17 Jul 2024 03:17:52 +0000 Original-Received: from localhost ([127.0.0.1]:34793 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sTvAt-00086Y-Te for submit@debbugs.gnu.org; Tue, 16 Jul 2024 23:17:52 -0400 Original-Received: from mail-108-mta121.mxroute.com ([136.175.108.121]:38475) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sTvAq-00086O-LT for 49860@debbugs.gnu.org; Tue, 16 Jul 2024 23:17:50 -0400 Original-Received: from filter006.mxroute.com ([136.175.111.3] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta121.mxroute.com (ZoneMTA) with ESMTPSA id 190beb2234100017a3.001 for <49860@debbugs.gnu.org> (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 17 Jul 2024 03:17:43 +0000 X-Zone-Loop: 52e5c7746786010bdf828ed9edf8caa1c90d118d03d3 X-Originating-IP: [136.175.111.3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=neverwas.me ; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To: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=MudfhPnErF+XGQcM5cMwMMLJ3tMU9Ng0LlIEm46U9oM=; b=joM+n+mYAdB6UGOA//qq+qoSDE xxskf2EomAKtSi9Raf4jBLQ7pb8enBjb/48Bwv2pfiqf+16iqajkdcXmYnDUrM83iKi/TVviN3lBG o6x31lscR4d9HL7blbu8jSdVkdG+70O3O9LtzNIrx3pdM0CnfA8YT2CcZeEh+yk/mfKrRcq7aQA8b KQqc1PsduGYrnTEfgJ7Jw7MwDnikcN7kKCq+amVLSUysq/C78ITIUsHVi0GlWd6to44UOdGCTyAnI sEYsuBe9BNIXA0sY3hxZd/4/zIGA/mRhfLmwB+g8gQ/w1T51WQt9ru58ff72G0Ey7yMJyTLx+p0UG q28Nz/rg==; In-Reply-To: <87wmllasjj.fsf@> ("=?UTF-8?Q?Bj=C3=B6rn?= Bidar"'s message of "Wed, 17 Jul 2024 01:19:44 +0300") X-Authenticated-Id: masked@neverwas.me 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:288905 Archived-At: Hi Bj=C3=B6rn, Bj=C3=B6rn Bidar writes: > How would IRv3 extension be implement as minor mode would work? > For example deactivating them does not work without reconnecting. > Further they are also interconnected you need some to activate others. It's true that minor modes tend to be user-facing with user-initiated activation: the user pulls a lever to toggle it on and off. With this design, the protocol pulls the lever, sometimes by way of other extensions when "interconnected," as you say. However, the user still controls which advertised subset gets activated. What _won't_ work is trying to run (erc-v3--foo +1) out of the blue and expecting ERC to activate `foo' somehow. That must be done via the protocol (and ultimately via user configuration). My intention in describing these extensions as conforming to the minor-mode interface (to whatever extent such a thing exists, even as a loosely defined set of requirements) was merely as shorthand to imply they provide setup and teardown code, a mode variable, etc. affecting functionality layered atop a major mode. But while this _does_ satisfy those fundamental requirements (and thus "implement" the interface), perhaps that's more of a technicality, and stressing the point will only cause confusion. Therefore, in the future, I will relegate all such mention of minor modes to a mere footnote. Thanks for raising this concern. > I think there are some where deactivating them doesn't make sense > to me such as for example the server-time extension where the client > will know when a message was send as opposed to not knowing it and > assuming that the time the message was send is the time the client > receives the message. Well, some module attempting to deactivate them itself via (erc-v3--foo -1) definitely won't work. But manually coaxing the protocol to do so on your behalf, i.e., /CAP REQ -server-time RET is indeed supported, albeit probably nonsensical and not recommended. Deactivating them because they've been DEL'd, however, is an actual requirement and obviously protocol-driven. Being asked to do that for `server-time' in particular is admittedly unlikely. I suppose in pathological cases, like a replication failover or a clock-sync/skew emergency, the network may need to disable stamps temporarily so they're not relayed to users (where they could cause havoc in logs). Anyway, ERC has been offering a mostly functional POC for users to try for years now. You can find the info elsewhere in this bug thread, just in case you're interested or are desperate to read some questionable code. However, I'm guessing "not very" since my records indicate you're a Circe user! (But I appreciate your input regardless.) Cheers, J.P.