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.erc.general,gmane.emacs.bugs Subject: Re: bug#68401: 30.0.50; ERC 5.6-git: `erc-cmd-GMSG', `erc-cmd-AMSG', `erc-cmd-GME', `erc-cmd-AME'. 2nd attempt Date: Mon, 22 Jan 2024 07:11:14 -0800 Message-ID: <87plxt2yjx.fsf@neverwas.me> References: <87v87yvnly.fsf@dataswamp.org> <834jfikb4d.fsf@gnu.org> <87mstavias.fsf@dataswamp.org> <87wmseoskl.fsf@dataswamp.org> <87plxyowpg.fsf__13716.8874776521$1705633220$gmane$org@neverwas.me> <87wms1k6xg.fsf@dataswamp.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19347"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-erc@gnu.org To: bug-gnu-emacs@gnu.org Original-X-From: emacs-erc-bounces+sf-erc-help=m.gmane-mx.org@gnu.org Mon Jan 22 16:11:36 2024 Return-path: Envelope-to: sf-erc-help@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 1rRvxY-0004qA-1w for sf-erc-help@m.gmane-mx.org; Mon, 22 Jan 2024 16:11:36 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rRvxP-00044D-1O; Mon, 22 Jan 2024 10:11:27 -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 1rRvxN-00043b-0U for emacs-erc@gnu.org; Mon, 22 Jan 2024 10:11:25 -0500 Original-Received: from mail-108-mta152.mxroute.com ([136.175.108.152]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rRvxK-0003UO-SV for emacs-erc@gnu.org; Mon, 22 Jan 2024 10:11:24 -0500 Original-Received: from filter006.mxroute.com ([136.175.111.2] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta152.mxroute.com (ZoneMTA) with ESMTPSA id 18d31b9d1080003727.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 22 Jan 2024 15:11:17 +0000 X-Zone-Loop: 5835715d7ed2e73305e4044ceac0593e5d33067b400e X-Originating-IP: [136.175.111.2] 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:Date:References:In-Reply-To: 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=93/dn6w3gIm5gHMbEY3RJtu1r4c8C+qj5bj1/Pm20+4=; b=RbYcqImYMgXszDqDiC9XnJK/P5 aIfBHT44+ZmH6aHrTmDYRMXZfSrRGp+FOkvXl0umE9SqXpO3QePiTYlgkzMDgI9gwof7u4HIRodeO t1EHXGY1gC1Far/s5ZXsAPiVUSs42jGUy9F0wKlHlNPTbOBCfDoD9gMZC+Qa9Eazd3E3xwrx7x1os zdOjgG+FnFqpFEKscIf3DFz8HL9Rn+SVXSJTBHwHTh+uumKnc4xhemjIg1A94FOKLTTDdkZc32BZ+ FXRhMmA/5vPSAY+v2YVbYoE1aEoqurXTpJl9dq+OPai6gaOXWzClLwTpWOPKqYkCtdsYPbfGq5gwJ 8eItNIbQ==; In-Reply-To: <87wms1k6xg.fsf@dataswamp.org> (Emanuel Berg's message of "Mon, 22 Jan 2024 11:18:19 +0100") X-Authenticated-Id: masked@neverwas.me Received-SPF: pass client-ip=136.175.108.152; envelope-from=jp@neverwas.me; helo=mail-108-mta152.mxroute.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-erc@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General discussion about ERC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-erc-bounces+sf-erc-help=m.gmane-mx.org@gnu.org Original-Sender: emacs-erc-bounces+sf-erc-help=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.erc.general:2384 gmane.emacs.bugs:278705 Archived-At: Emanuel Berg writes: > J.P. wrote: > >> Make erc-cmd-AMSG session-local, add /GMSG /AME /GME >> >> * lisp/erc/erc.el (erc-cmd-AMSG): Make good on behavior described in >> the doc string by limiting damage to the current connection. >> (erc-cmd-GMSG, erc-cmd-GME, erc-cmd-AME): New functions, all IRC >> "slash commands". (Bug#68401) > > Okay, I'll use that instead. But let's agree on the > source first. > >> I question the wisdom of having new slash commands serve >> double duty as interactive Emacs commands (at least those >> handling chat input). This reservation has nothing to do >> with M-x erc-cmd-FOO being less faithful (or whatever) >> to the traditional IRC experience than /FOO . Rather, >> it stems from a need to prioritize consistent feedback and >> promote maintainability by only having a single path for >> chat input to reach the server (except under special >> circumstances). > > I made them interactive as `erc-cmd-AMSG' is interactive, but > let's remove it from the other three then. > > [ As a side note, Emacs has a problem with different > interfaces doing too much and influencing the behavior of > their functions. Interfaces should just be different ways of > setting the formal parameters, after that the exact same > thing should happen for the same data. ] > >>> (setq line (erc-trim-string line)) >> >> It might be nice to remove at most one space, for cases >> where a user wants to send preformatted text. OTOH, normal >> /MSG doesn't do this, so perhaps we shouldn't here either. > > Again, this is in the original `erc-cmd-AMSG'. I have no > opinion, so you can decide it. > > "At most one space", what space should that be? Leading or > trailing? Leading. See the test for `erc-extract-command-from-line' to understand the behavior of `do-not-parse-args', which determines LINE. Actually, if we're doing away with `commandp', there should be no reason for "at most one," only "exactly one" (IIRC). > This is nothing `erc-trim-string' can do BTW. But we > can of course still remove whatever spaces we like. I wasn't implying you ought to change `erc-trim-string' but rather that you can replace its call with an expression to remove a leading space. > >>> (erc-with-all-buffers-of-server nil >>> - (lambda () >>> - (erc-channel-p (erc-default-target))) >>> + (lambda () (erc-channel-p (erc-default-target))) >>> + (erc-send-message line))) >> >> Without first checking for connectivity, we run into another >> situation in which messages may be inserted but not sent, >> similar to the bit about commands being potentially >> "misleading," above. The most obvious way to solve this is >> to check for "physical" connectivity with something like: >> >> (erc-with-all-buffers-of-server nil #'erc-server-process-alive >> (when (and erc--target (erc--current-buffer-joined-p)) >> (erc-send-message line)))) >> >> Alternatively, you can check for "logical" connectivity, >> which is probably more in keeping with traditional design >> principles: >> >> (erc-with-all-buffers-of-server nil nil >> (when (and erc-server-connected erc--target (erc--current-buffer-joined-p)) >> (erc-send-message line)))) >> >> One minor downside of this second method is that IRC >> adjacent protocols and aberrant proxy servers that happen to >> skip 376/422 and also provide some (possibly &local) >> "control channel" won't be detected. (BTW, you won't be >> needing the `erc--target' in either example if you rebase >> atop the latest master.) > > Okay, but instead of having these checks embedded and hopefully > correctly repeated four times, shouldn't we have two functions, say > "erc-connected-physical-p" and "erc-connected-logical-p" and call > either of those (or both) from the functions? If you want to factor out a common helper function, fine by me. AFAICT such a thing would need to include `erc-with-all-buffers-of-server' to be effective unless the predicates you've named alone result in meaningful code reuse. (Not sure how an `erc-connected-physical-p' would be any different than the existing 'erc-server-process-alive', though I suppose an `erc-connected-logical-p' could be useful if it just returns `erc-server-connected'.) >>> +(put 'erc-cmd-GMSG 'do-not-parse-args t) >>> + >>> +(defun erc-cmd-AMSG (line) >>> + "Send LINE to all channels of the current network. >>> +Interactively, prompt for the line of text to send." >>> + (interactive "sSend to all channels on this network: ") >>> + (setq line (erc-trim-string line)) >>> + (erc-with-all-buffers-of-server erc-server-process >>> + (lambda () (erc-channel-p (erc-default-target))) >> >> ^ Indentation. This macro is declared "indent 2" > > Okay, fixed that. > >> rebase > > How do you do that, just 'git pull'? Assuming you have your work on "my-branch" $ git checkout master $ git pull $ git rebase master my-branch. If you applied the unit-test patch atop your commit, you won't be able to "git commit --amend" your previous changes. See the "-i, --interactive" option for git-rebase(1), then maybe rearrange things so your patch comes *after* the test. You can always "git rebase --abort" if you mess up. And there's always #git on Libera.