* [PATCH] ERC: support for IRCv3.1 CAP
@ 2016-06-21 7:26 Vibhav Pant
2016-06-21 15:22 ` Kelvin White
0 siblings, 1 reply; 7+ messages in thread
From: Vibhav Pant @ 2016-06-21 7:26 UTC (permalink / raw
To: emacs-devel@gnu.org
[-- 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")
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] ERC: support for IRCv3.1 CAP
2016-06-21 7:26 [PATCH] ERC: support for IRCv3.1 CAP Vibhav Pant
@ 2016-06-21 15:22 ` Kelvin White
2016-06-25 14:04 ` Vibhav Pant
0 siblings, 1 reply; 7+ messages in thread
From: Kelvin White @ 2016-06-21 15:22 UTC (permalink / raw
To: Vibhav Pant; +Cc: emacs-devel@gnu.org
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?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] ERC: support for IRCv3.1 CAP
2016-06-21 15:22 ` Kelvin White
@ 2016-06-25 14:04 ` Vibhav Pant
2016-09-22 16:06 ` Vibhav Pant
0 siblings, 1 reply; 7+ messages in thread
From: Vibhav Pant @ 2016-06-25 14:04 UTC (permalink / raw
To: Kelvin White; +Cc: emacs-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] ERC: support for IRCv3.1 CAP
2016-06-25 14:04 ` Vibhav Pant
@ 2016-09-22 16:06 ` Vibhav Pant
2016-09-22 17:35 ` Kelvin White
2016-09-22 17:51 ` John Wiegley
0 siblings, 2 replies; 7+ messages in thread
From: Vibhav Pant @ 2016-09-22 16:06 UTC (permalink / raw
To: Kelvin White; +Cc: emacs-devel@gnu.org
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] ERC: support for IRCv3.1 CAP
2016-09-22 16:06 ` Vibhav Pant
@ 2016-09-22 17:35 ` Kelvin White
2016-09-22 17:51 ` John Wiegley
1 sibling, 0 replies; 7+ messages in thread
From: Kelvin White @ 2016-09-22 17:35 UTC (permalink / raw
To: Vibhav Pant; +Cc: emacs-devel@gnu.org
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] ERC: support for IRCv3.1 CAP
2016-09-22 16:06 ` Vibhav Pant
2016-09-22 17:35 ` Kelvin White
@ 2016-09-22 17:51 ` John Wiegley
2016-09-22 18:00 ` Vibhav Pant
1 sibling, 1 reply; 7+ messages in thread
From: John Wiegley @ 2016-09-22 17:51 UTC (permalink / raw
To: Vibhav Pant; +Cc: Kelvin White, emacs-devel@gnu.org
>>>>> "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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] ERC: support for IRCv3.1 CAP
2016-09-22 17:51 ` John Wiegley
@ 2016-09-22 18:00 ` Vibhav Pant
0 siblings, 0 replies; 7+ messages in thread
From: Vibhav Pant @ 2016-09-22 18:00 UTC (permalink / raw
To: emacs-devel, Kelvin White
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2016-09-22 18:00 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-06-21 7:26 [PATCH] ERC: support for IRCv3.1 CAP Vibhav Pant
2016-06-21 15:22 ` Kelvin White
2016-06-25 14:04 ` Vibhav Pant
2016-09-22 16:06 ` Vibhav Pant
2016-09-22 17:35 ` Kelvin White
2016-09-22 17:51 ` John Wiegley
2016-09-22 18:00 ` Vibhav Pant
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.