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#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 13:27:28 -0800 Message-ID: <87zfwxxdmn.fsf__6793.81943061657$1705958905$gmane$org@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> <87plxt2yjx.fsf@neverwas.me> <87ttn5job9.fsf@dataswamp.org> <87r0i9jhp6.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="29563"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-erc@gnu.org To: 68401@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jan 22 22:28:17 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 1rS1q3-0007Si-Gj for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 22 Jan 2024 22:28:15 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rS1po-0005FE-GT; Mon, 22 Jan 2024 16:28:00 -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 1rS1pn-0005F1-2h for bug-gnu-emacs@gnu.org; Mon, 22 Jan 2024 16:27:59 -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 1rS1pm-0004lx-KM for bug-gnu-emacs@gnu.org; Mon, 22 Jan 2024 16:27:58 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rS1pq-0008FD-6e for bug-gnu-emacs@gnu.org; Mon, 22 Jan 2024 16:28:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "J.P." Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 22 Jan 2024 21:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 68401 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 68401-submit@debbugs.gnu.org id=B68401.170595886531665 (code B ref 68401); Mon, 22 Jan 2024 21:28:02 +0000 Original-Received: (at 68401) by debbugs.gnu.org; 22 Jan 2024 21:27:45 +0000 Original-Received: from localhost ([127.0.0.1]:41848 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rS1pY-0008Ed-Of for submit@debbugs.gnu.org; Mon, 22 Jan 2024 16:27:45 -0500 Original-Received: from mail-108-mta216.mxroute.com ([136.175.108.216]:38799) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rS1pT-0008ER-IT for 68401@debbugs.gnu.org; Mon, 22 Jan 2024 16:27:43 -0500 Original-Received: from filter006.mxroute.com ([136.175.111.2] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta216.mxroute.com (ZoneMTA) with ESMTPSA id 18d331242fa0003727.001 for <68401@debbugs.gnu.org> (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 22 Jan 2024 21:27:31 +0000 X-Zone-Loop: f6e85c3d1ec63b4360d8281641d1ae7564453cfb453b 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=HZpOUcwjIdO8mbH3VqA6S0OoukiEhvTZw+PT5MZcjiw=; b=aw8QTmyW1XuwCWu8c6+jqMcw7I Cw5NgLs9YBI4FOhuYrfZhVTdMymGYQD3U0zOPFhQXmxSFo2pGckxE9e35SoaPwWqfBRY06mXfd1kz xJwL0Q+LCn0f4ELLHsk4ZnMuUODW2s67xOIXjZTLow4HvV5ynK4gVVH77/mVOUFoFKiuIGaZCQfaR cA/V2SNQkYOF81voigHbX2jS/OPb/tZ4IlVQqUOtjunuZi7VmBgk1Cq3QlobQZGgfg8vOF+bo4/m0 aPHqKCg/AWWHX/B39AS380dhop1+5u/7AO41W5jtrWEYtEIeZMZ61uZQS5XYQ4wN/knx9bfSw9B8P KA6uEgOw==; In-Reply-To: <87r0i9jhp6.fsf@dataswamp.org> (Emanuel Berg's message of "Mon, 22 Jan 2024 20:23:17 +0100") 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:278716 Archived-At: Emanuel Berg writes: >>>>> 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). >> >> So if and only if the initial char is a whitespace, it, and >> only it, should be dropped. E.g. " line string " should be >> transformed into " line string ". >> >> Also, at this point, only "erc-cmd-AMSG" and "erc-cmd-GMSG" >> has the trim line, and the reason is it is present in the >> original `erc-cmd-AMSG'. >> >> Should we also have the new one in `erc-cmd-AME' and >> `erc-cmd-GME'? Please look at the "source" of `erc-cmd-ME', which these commands both call, and you will (hopefully) have your answer. > Andreas Schwab wrote: > >> (defun erc-drop-leading-whitespace (str) > >> (if (string-match " \\(.*\\)" str) > >> (match-string 1 str) > >> str) ) > > > > (erc-drop-leading-whitespace "foo bar") => "bar" > Ah, forgot the ^ and $, thank you. > (defun erc-drop-leading-whitespace (str) > (if (string-match "^ \\(.*\\)$" str) > (match-string 1 str) > str) ) Why not use `string-prefix-p' and `substring' to accomplish this? Also, please name this using the internal "--" convention, something like `erc--drop-initial-space-char' or `erc--drop-single-leading-space'. >>>>> 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)))) > > If we can drop `erc--target' in the latest Emacs source as you > say that means there is only this left > > (and (erc-server-process-alive) (erc--current-buffer-joined-p)) Correct. >>>>> 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)))) > > If we again can drop `erc--target' and want > `erc-server-connected' to be returned upon success we can do > > (and (erc--current-buffer-joined-p) erc-server-connected) Correct. > If we unify those two tests it will be > > (defun erc-connected-and-joined-p () > (and (erc-server-process-alive) > (erc--current-buffer-joined-p) > erc-server-connected)) No! Well... it's superfluous and hand wavy, and we ought not conflate the two unless we're going into the chimera breeding business, in which case we'd want (and (erc--current-buffer-joined-p) (or erc-server-connected (erc-server-process-alive))) Regardless, the confusion here is my fault because I should never have mentioned `erc-server-process-alive' to begin with. The corner cases in which (when (erc-server-process-alive) (cl-assert erc-server-connected)) actually signals are rare, and we can safely ignore them, at least in this context. Although, it's worth noting that the reverse of (when erc-server-connected (cl-assert (erc-server-process-alive))) is an operating invariant that must never signal unless we're tearing down a session. But let's just drop the `erc-server-process-alive' business if you don't mind. Also, `erc-connected-and-joined-p' should be `erc--connected-and-joined-p' unless you can find at least one more person to +1 exporting it.