[PATCH] ERC: support for IRCv3.1 CAP

[PATCH] ERC: support for IRCv3.1 CAP

[Vibhav Pant]

[-- Attachment #1: Type: text/plain, Size: 305 bytes --]

The IRCv3.1 specification adds the CAP command, allowing
client/servers to enable/disable certain capabilities. The following
patch adds the CAP command, and the response handler for CAP LS, LIST,
REQ, ACK, NAK and error 410 (ERR_INVALIDCAPCMD) messages.

Thanks,
Vibhav
-- 
Vibhav Pant
vibhavp@gmail.com

[-- Attachment #2: cap.diff --]
[-- Type: text/plain, Size: 3977 bytes --]

diff --git a/lisp/erc/erc-backend.el b/lisp/erc/erc-backend.el
index bbb7ccb..3fe252a 100644
--- a/lisp/erc/erc-backend.el
+++ b/lisp/erc/erc-backend.el
@@ -1528,6 +1528,31 @@ erc-handle-unknown-server-response
        parsed 'notice nil
        'WALLOPS ?n nick ?m message))))
 
+(define-erc-response-handler (CAP)
+  "capabilities" nil
+  (let ((subcmd (nth 1 (erc-response.command-args parsed))))
+    (cond
+     ((string-equal subcmd "LS")
+      (erc-display-message
+       parsed 'notice nil
+       'CAPLS ?c (string-join
+                  (cddr (erc-response.command-args parsed)) " ")))
+     ((string-equal subcmd "LIST")
+      (erc-display-message
+       parsed 'notice nil
+       'CAPLIST ?c (string-join
+                    (cddr (erc-response.command-args parsed)) " ")))
+     ((string-equal subcmd "ACK")
+      (erc-display-message
+       parsed 'notice nil
+       'CAPACK ?c (string-join
+                   (cddr (erc-response.command-args parsed)) " ")))
+     ((string-equal subcmd "NAK")
+      (erc-display-message
+       parsed '(notice error) nil
+       'CAPNAK ?c (string-join
+                   (cddr (erc-response.command-args parsed)) " "))))))
+
 (define-erc-response-handler (001)
   "Set `erc-server-current-nick' to reflect server settings and display the welcome message."
   nil
@@ -2012,6 +2037,11 @@ erc-server-322-message
     (erc-display-message parsed 'notice 'active 's671
                          ?n nick ?a securemsg)))
 
+(define-erc-response-handler (410)
+  "Invalid CAP subcommand" nil
+  (erc-display-message parsed '(notice error) nil 's410
+                       ?c (nth 1 (erc-response.command-args parsed))))
+
 (define-erc-response-handler (431 445 446 451 462 463 464 481 483 484 485
                                   491 501 502)
   ;; 431 - No nickname given
diff --git a/lisp/erc/erc.el b/lisp/erc/erc.el
index 8501e2c..72b52d0 100644
--- a/lisp/erc/erc.el
+++ b/lisp/erc/erc.el
@@ -3832,6 +3832,35 @@ erc-cmd-MASSUNBAN
 
 (defalias 'erc-cmd-MUB 'erc-cmd-MASSUNBAN)
 
+(defun erc-cap-command (cmd param)
+  (erc-server-send
+   (format "CAP %s %s" cmd
+           (if (= (length param) 0) (nth 0 param)
+             (concat ":" (string-join param " ")))))
+  (erc-server-send "CAP END"))
+
+(defun erc-cmd-CAP (subcmd &rest params)
+  "IRCv3 Capability negotation.
+
+/cap REQ PARAMS requests a the server to enable capabilities PARAMS.
+Capabilities prefixed with '-' are disabled.
+
+/cap ACK PARAMS acknowledges a change for capabilities PARAMS.  Capabilities
+prefixed with '-' are acknowledged as disabled.
+
+/cap LS lists capabilities supported by the server.
+
+/cap LIST lists capabilities associated with this connection.
+
+/cap END ends capability negotiation."
+  (cond
+   ((string= "REQ" (upcase subcmd))
+    (erc-cap-command "REQ" params))
+   ((string= "ACK" (upcase subcmd))
+    (erc-cap-command "ACK" params))
+   (t (erc-server-send (format "CAP %s %s" (upcase subcmd)
+                               (string-join params " "))))))
+
 ;;;; End of IRC commands
 
 (defun erc-ensure-channel-name (channel)
@@ -6544,6 +6573,10 @@ erc-define-catalog
    (undefined-ctcp . "Undefined CTCP query received. Silently ignored")
    (variable-not-bound . "Variable not bound!")
    (ACTION . "* %n %a")
+   (CAPACK . "Capability change acknowledged: %c")
+   (CAPLS . "Capabilities supported by the server: %c")
+   (CAPLIST . "Capabilities active on this connection: %c")
+   (CAPNAK . "Capability change was rejected for: %c")
    (CTCP-CLIENTINFO . "Client info for %n: %m")
    (CTCP-ECHO . "Echo %n: %m")
    (CTCP-FINGER . "Finger info for %n: %m")
@@ -6609,6 +6642,7 @@ erc-define-catalog
    (s404   . "%c: Cannot send to channel")
    (s405   . "%c: You have joined too many channels")
    (s406   . "%n: There was no such nickname")
+   (s410   . "Invalid CAP subcommand: %c")
    (s412   . "No text to send")
    (s421   . "%c: Unknown command")
    (s431   . "No nickname given")

Re: [PATCH] ERC: support for IRCv3.1 CAP

[Kelvin White]

On Tue, Jun 21, 2016 at 3:26 AM, Vibhav Pant <vibhavp@gmail.com> wrote:
>
> The IRCv3.1 specification adds the CAP command, allowing
> client/servers to enable/disable certain capabilities. The following
> patch adds the CAP command, and the response handler for CAP LS, LIST,
> REQ, ACK, NAK and error 410 (ERR_INVALIDCAPCMD) messages.
>

I'm not sure that this is needed. Why does ERC need to implement CAP support?

Re: [PATCH] ERC: support for IRCv3.1 CAP

[Vibhav Pant]

[-- Attachment #1: Type: text/plain, Size: 770 bytes --]

Most popular clients and servers have already started supporting IRCv3, so
I thought it would be a good idea to have some basic functionality for CAP
in ERC. (Twitch already uses it to enable JOIN and PART messages, necessary
for building the user list for a channel)

On 21 Jun 2016 20:52, "Kelvin White" <kwhite@gnu.org> wrote:

> On Tue, Jun 21, 2016 at 3:26 AM, Vibhav Pant <vibhavp@gmail.com> wrote:
> >
> > The IRCv3.1 specification adds the CAP command, allowing
> > client/servers to enable/disable certain capabilities. The following
> > patch adds the CAP command, and the response handler for CAP LS, LIST,
> > REQ, ACK, NAK and error 410 (ERR_INVALIDCAPCMD) messages.
> >
>
> I'm not sure that this is needed. Why does ERC need to implement CAP
> support?
>

[-- Attachment #2: Type: text/html, Size: 1135 bytes --]

Re: [PATCH] ERC: support for IRCv3.1 CAP

[Vibhav Pant]

Now that Emacs 25.1 is out, could this be reviewed again? I'd like to
add support for more IRCv3 features (http://ircv3.net/irc/) for this
development cycle.

On Sat, Jun 25, 2016 at 7:34 PM, Vibhav Pant <vibhavp@gmail.com> wrote:
> Most popular clients and servers have already started supporting IRCv3, so I
> thought it would be a good idea to have some basic functionality for CAP in
> ERC. (Twitch already uses it to enable JOIN and PART messages, necessary for
> building the user list for a channel)
>
>
> On 21 Jun 2016 20:52, "Kelvin White" <kwhite@gnu.org> wrote:
>>
>> On Tue, Jun 21, 2016 at 3:26 AM, Vibhav Pant <vibhavp@gmail.com> wrote:
>> >
>> > The IRCv3.1 specification adds the CAP command, allowing
>> > client/servers to enable/disable certain capabilities. The following
>> > patch adds the CAP command, and the response handler for CAP LS, LIST,
>> > REQ, ACK, NAK and error 410 (ERR_INVALIDCAPCMD) messages.
>> >
>>
>> I'm not sure that this is needed. Why does ERC need to implement CAP
>> support?



-- 
Vibhav Pant
vibhavp@gmail.com

Re: [PATCH] ERC: support for IRCv3.1 CAP

[Kelvin White]

On Thu, Sep 22, 2016 at 12:06 PM, Vibhav Pant <vibhavp@gmail.com> wrote:
> Now that Emacs 25.1 is out, could this be reviewed again? I'd like to
> add support for more IRCv3 features (http://ircv3.net/irc/) for this
> development cycle.

Sure thing! This is actually on my list for next week. :)

-- 
Good code is like a good joke - it needs no explanation.
-- Russ Olsen

Re: [PATCH] ERC: support for IRCv3.1 CAP

[John Wiegley]

>>>>> "VP" == Vibhav Pant <vibhavp@gmail.com> writes:

VP> Now that Emacs 25.1 is out, could this be reviewed again? I'd like to add
VP> support for more IRCv3 features (http://ircv3.net/irc/) for this
VP> development cycle.

How destabilizing do you think these changes will be?  If it's significant new
development, then 'master' is the best place.  But if they are minor, and
purely additions, I suppose we could consider it for 25.2.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: [PATCH] ERC: support for IRCv3.1 CAP

[Vibhav Pant]

[-- Attachment #1: Type: text/plain, Size: 833 bytes --]

Adding support for message tags would require significant changes to ERC's
message parser. I'd suppose it is well suited for master instead of 25.2.

On 22 Sep 2016 23:21, "John Wiegley" <jwiegley@gmail.com> wrote:

> >>>>> "VP" == Vibhav Pant <vibhavp@gmail.com> writes:
>
> VP> Now that Emacs 25.1 is out, could this be reviewed again? I'd like to
> add
> VP> support for more IRCv3 features (http://ircv3.net/irc/) for this
> VP> development cycle.
>
> How destabilizing do you think these changes will be?  If it's significant
> new
> development, then 'master' is the best place.  But if they are minor, and
> purely additions, I suppose we could consider it for 25.2.
>
> --
> John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
> http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2
>

[-- Attachment #2: Type: text/html, Size: 1412 bytes --]