From: "J.P." <jp@neverwas.me>
To: 68401@debbugs.gnu.org
Cc: emacs-erc@gnu.org
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 [thread overview]
Message-ID: <87zfwxxdmn.fsf__6793.81943061657$1705958905$gmane$org@neverwas.me> (raw)
In-Reply-To: <87r0i9jhp6.fsf@dataswamp.org> (Emanuel Berg's message of "Mon, 22 Jan 2024 20:23:17 +0100")
Emanuel Berg <incal@dataswamp.org> 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.
next prev parent reply other threads:[~2024-01-22 21:27 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87v87yvnly.fsf@dataswamp.org>
2024-01-12 12:08 ` bug#68401: 30.0.50; ERC 5.6-git: `erc-cmd-GMSG', `erc-cmd-AMSG', `erc-cmd-GME', `erc-cmd-AME'. 2nd attempt Eli Zaretskii
2024-01-12 14:12 ` Emanuel Berg
2024-01-12 14:39 ` Eli Zaretskii
2024-01-13 2:09 ` Emanuel Berg
2024-01-13 2:31 ` Emanuel Berg
2024-01-13 2:45 ` Emanuel Berg
2024-01-13 7:23 ` Eli Zaretskii
2024-01-14 9:11 ` Emanuel Berg
[not found] ` <834jfikb4d.fsf@gnu.org>
2024-01-12 12:36 ` Emanuel Berg
[not found] ` <87ply6vidl.fsf@dataswamp.org>
2024-01-12 14:03 ` Eli Zaretskii
2024-01-12 14:30 ` Emanuel Berg
[not found] ` <87mstavias.fsf@dataswamp.org>
[not found] ` <87wmseoskl.fsf@dataswamp.org>
2024-01-19 2:58 ` J.P.
2024-01-22 10:18 ` Emanuel Berg
2024-01-22 15:11 ` J.P.
2024-01-22 17:00 ` Emanuel Berg
2024-01-22 19:23 ` Emanuel Berg
[not found] ` <87y1ch851b.fsf@igel.home>
2024-01-22 21:05 ` Emanuel Berg
2024-01-22 21:27 ` J.P. [this message]
2024-01-23 4:25 ` Emanuel Berg
2024-01-23 4:32 ` Emanuel Berg
2024-01-23 6:20 ` Emanuel Berg
2024-01-23 13:31 ` Emanuel Berg
2024-01-24 0:36 ` J.P.
2024-01-24 0:56 ` Emanuel Berg
2024-01-24 1:38 ` J.P.
2024-01-24 2:01 ` Emanuel Berg
2024-01-23 13:42 ` Emanuel Berg
2024-01-24 0:34 ` J.P.
2024-01-24 1:28 ` Emanuel Berg
2024-01-24 1:38 ` Emanuel Berg
2024-01-24 11:15 ` Emanuel Berg
2024-01-24 11:55 ` Emanuel Berg
2024-02-05 0:52 ` Emanuel Berg
2024-02-06 3:44 ` J.P.
2024-02-11 1:58 ` Emanuel Berg
2024-02-11 2:27 ` Emanuel Berg
2024-02-11 3:30 ` Emanuel Berg
2024-02-11 3:52 ` Emanuel Berg
2024-02-14 1:42 ` J.P.
2024-02-17 5:21 ` Emanuel Berg
2024-02-17 8:52 ` Emanuel Berg
2024-02-21 1:11 ` J.P.
[not found] ` <87ttm2boza.fsf@neverwas.me>
2024-02-21 1:16 ` Emanuel Berg
2024-03-01 0:18 ` J.P.
2024-01-12 10:43 Emanuel Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='87zfwxxdmn.fsf__6793.81943061657$1705958905$gmane$org@neverwas.me' \
--to=jp@neverwas.me \
--cc=68401@debbugs.gnu.org \
--cc=emacs-erc@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.