CTCP not according to specifcation?

[Querela]

https://github.com/Shizmob/pydle/blob/60ede96669d77e86b8ee264ebc21ab669418fb7b/pydle/features/ctcp.py#L102

I think, there may be cases where CTCP is not correctly recognized. More specifically, if the CTCP message follows a normal text message (or is embedded in it).

see example 3 in http://www.irchelp.org/protocol/ctcpspec.html

---

The text part of a PRIVMSG or NOTICE might contain zero or more
extended messages, intermixed with zero or more chunks of non-extended
data.
https://github.com/irchelp/wio/blame/gh-pages/protocol/ctcpspec.md#L189

Furthermore, it should be possible to send multiple CTCP messages (chained together). A check for CTCP should therefore
(1) check for CTCP_DELIMITER and if found
(2) check/extract all CTCP messages.
(3) handle CTCP messages/handle remaining text messages (if available)

---

I'm not sure how CTCP (aside from DCC) occurs in the wild but the current approach may not work for all cases.

[rakiru]

Basically no client implements the original CTCP spec. The only real potential case where it doesn't catch current usage is where message splitting results in the last character not being the delimiter any more.

A draft of an updated spec that details what is commonly implemented today: https://tools.ietf.org/html/draft-oakley-irc-ctcp-02

[shizmob]

This seems important to double-check, thanks! I'll see if there's any cases out there that aren't caught by current pydle.