Add support for /cap command about weechat HOT 7 CLOSED

Weechat already supports CAP.

irc.server_default.capabilities
description: comma-separated list of client capabilities to enable for server if they are available; capabilities supported by WeeChat are: multi-prefix, userhost-in-names (example: "multi-prefix,userhost-in-names")
type: string
values: any string (default value: "")

I don't think a /cap command is needed as this isn't a command a user needs to send at all. You configure the client with the capabilities you want that your client supports, and it'll negotiate on your behalf when connecting.

If you really want this you can just alias /cap to /quote cap.

from weechat.

Or

/set irc.network.send_unknown_commands on

from weechat.

EDITED

It's perfectly reasonable to use /cap while being connected, in case you changed the capabilities in the config but don't want to reconnect, or you want to temporarily enable/disable capabilities. Since WeeChat supports fancy output for CAP-related numerics, I think this would be a reasonable addition. Furthermore, there's /sajoin and friends, which aren't a standard as far as I know, whereas CAP is an IRCv3 standard.

from weechat.

@nyuszika7h What use would a regular user get out of being able to issue /cap? After asking in #ircv3 I can find no valid use for a regular using using /cap.

grawity | a client should always react to a received CAP ACK apropriately
grawity | so it would work both when the client issued /cap, and when the user did so for debugging or whatever reasons
grawity | same as any other command
grawity | but, other than that, I don't see why regular users would use it

It seems like a waste to add cap as its own command when the only time a user will issue it is during debugging and testing, especially when there is no added benefit of giving it it's own command instead of aliasing it to quote cap, or setting send_unknown_commands to on.

from weechat.

On another note, WeeChat ignores the server's response to /cap list, is that intentional? (It could be useful for debugging even if a /cap command isn't added.)

from weechat.

@nyuszika7h I opened a pull request to fix the /cap list being ignored. Until that is accepted or something else is done to fix that you can still view the output of /cap list by opening the raw buffer with alt-j + alt-r

from weechat.

It's perfectly reasonable to use /cap while being connected, in case you changed the capabilities in the config but don't want to reconnect, or you want to temporarily enable/disable capabilities.

A user-friendly approach here would be to not let them request (etc.) a cap and potentially mess everything up without confirmation; if you let them send arbitrary CAP messages you can desync badly if they request something you don't understand.

EDIT: clarification.

from weechat.