I think most of us agree that / commands are not a good user interface for graphical programs. But that question aside, the Telepathy framework does not provide a way for clients to inject arbitrary commands into the protocol, and I think this is probably a good thing.

I understand that you may not like / commands, but unless users have the ability to do all the things that one can do in a normal IRC client, then it makes it impossible to use telepathy-idle for day-to-day IRC usage.  I use IRC every day as part of communication in my job.  We don't view a user having access to / commands as any form of security risk because that can all be controlled on the IRC server itself.

Currently I have to revert to using pidgin (which does allow such commands) because the channels I use are password protected and I need to be able to give a password specific to that channel.

That aside, many popular IRC servers use various slash commands for controlling moderated channels and such. A quick /help on irc.freenode.net gives us:

action, away, chanserv, clear, clearall, ctcp, debug, deop, devoice, help, invite, j, join, kick, list, me, memoserv, mode, msg, names, nick, nickserv, notice, op, operserv, operwall, part, ping, query, quit, quote, remove, say, time, topic, umode, version, voice, wallops, whois, whowas.

Unless telepathy-idle provides methods for doing all of these basic commands, then it doesn't really fulfill the requirements for providing IRC functionality.  The methods provided must be able to take the same arguments that each of these commands do (for example, empathy gives a way of joining channels but not passworded channels).  So either telepathy-idle should give fully-featured graphical methods for all of these, or (much easier in my opinion) it should just forward any line starting with a '/' to the server rather than saying it.

I honestly want to be able to move from pidgin to empathy but don't feel I can until at least the basic IRC commands are supported.

I understand your problem: I'm speaking as a Telepathy developer who uses Empathy for Jabber and irssi for IRC. (Largely because of inertia, but also because I like irssi's UI better for multi-user conversations, and it lets me keep a permanent IRC session.)

(In reply to comment #2)
> I understand that you may not like / commands, but unless users have the
> ability to do all the things that one can do in a normal IRC client, then it
> makes it impossible to use telepathy-idle for day-to-day IRC usage.  I use IRC
> every day as part of communication in my job.  We don't view a user having
> access to / commands as any form of security risk because that can all be
> controlled on the IRC server itself.

I'm not particularly worried about security, it's that it introduces protocol-specific dependencies, which we try to avoid (for the sake of client simplicity and portability of clients between protocols). Also, it means that idle has to work out which data coming from the server is in response to commands it didn't issue itself, and pass that information to the client, which it then has to parse itself. It's been a wihle since I implemented the IRC protocol, but if I recall correctly then this is not a simple matter. Idle developers might be able to correct me here.

> Currently I have to revert to using pidgin (which does allow such commands)
> because the channels I use are password protected and I need to be able to give
> a password specific to that channel.

I agree that Empathy should support joining channels with passwords, but that is a different bug.

> That aside, many popular IRC servers use various slash commands for controlling
> moderated channels and such. A quick /help on irc.freenode.net gives us:
> 
> action, away, chanserv, clear, clearall, ctcp, debug, deop, devoice, help,
> invite, j, join, kick, list, me, memoserv, mode, msg, names, nick, nickserv,
> notice, op, operserv, operwall, part, ping, query, quit, quote, remove, say,
> time, topic, umode, version, voice, wallops, whois, whowas.

This is not a helpful list. For instance:

 - action is the same as me
 - chanserv, memoserv, nickserv, and operserv can all be used without specific commands
 - Empathy provides UI for join/part/quit/say/list/away

Some of the commands for managing modes might be useful, but that is again a different bug.

> Unless telepathy-idle provides methods for doing all of these basic commands,
> then it doesn't really fulfill the requirements for providing IRC
> functionality.  The methods provided must be able to take the same arguments
> that each of these commands do (for example, empathy gives a way of joining
> channels but not passworded channels).  So either telepathy-idle should give
> fully-featured graphical methods for all of these, or (much easier in my
> opinion) it should just forward any line starting with a '/' to the server
> rather than saying it.
> 
> I honestly want to be able to move from pidgin to empathy but don't feel I can
> until at least the basic IRC commands are supported.

Your list doesn't just contain basic commands. Which commands do you feel you really need?

There is certainly a tension between the Telepathy design and the nature of common IRC clients. It would be nice to be able to have a Telepathy client that is also a comprehensive IRC client, but I don't think passing through protocol is the right way to do it.

> I'm not particularly worried about security, it's that it introduces
> protocol-specific dependencies, which we try to avoid (for the sake of client
> simplicity and portability of clients between protocols). Also, it means that
> idle has to work out which data coming from the server is in response to
> commands it didn't issue itself,and pass that information to the client, which
> it then has to parse itself. It's been a wihle since I implemented the IRC
> protocol, but if I recall correctly then this is not a simple matter. Idle
> developers might be able to correct me here.

You are right that this does sound more complicated.  And yes, I can see that protocol-specific dependencies, especially in the front end through providing GUI equivalencies.

> I agree that Empathy should support joining channels with passwords, but that
> is a different bug.

True, I think it is an important bug, but it was just an example.  Are you saying I should open one bug for each / command that I can't find a GUI alternative to?  I mean I'm willing to do that but it seemed more like something one of the developers might want to consider en masse so that they were all implemented in the same manner.

>> That aside,many popular IRC servers use various slash commands for 
>> moderated channels and such. A quick /help on irc.freenode.net gives us:
>> action, away, chanserv, clear, clearall, ctcp, debug, deop, devoice, help,
>> invite, j, join, kick, list, me, memoserv, mode, msg, names, nick, nickserv,
>> notice, op, operserv, operwall, part, ping, query, quit, quote, remove, say,
>> time, topic, umode, version, voice, wallops, whois, whowas.
> 
> This is not a helpful list. For instance:
> 
>  - action is the same as me
>  - chanserv, memoserv, nickserv, and operserv can all be used without specific
> commands
>  - Empathy provides UI for join/part/quit/say/list/away
> 
> Some of the commands for managing modes might be useful, but that is again a
> different bug.

Sure, as I said that was the output from /help on irc.freenode.net, so yes, lots of duplicates.  And while Empathy does provide a GUI for some of those things, in some instances it is much more complicated to use.  Consider "/quit 'Message'".  True you can set an optional quit message by going to Accounts, selecting the account, changing the default quit message, closing that, then quitting.  (I've not tested, I assume it uses the new message.)  But when you just want to do "/quit I'll be back in a few minutes" or something that seems like an awful lot of hassle.  But again, that is just an example of the problems of having a GUI alternative to commands like this.

> Your list doesn't just contain basic commands. Which commands do you feel you
> really need?

Ok, you are right that some of them are provided, and the list was just default output of /help so not just basic commands.

In addition to: /join/part/quit/say/list/away/me/names (and /msg of course) which I think it already provides in one way or another I would think that:

useful: /deop/devoice/invite/kick/mode/nick/op/topic/umode/voice/whois
less necessary: /clear/ctcp/quote/time/whowas
and the others either being duplicates or things an average user/moderator probably doesn't need to do.

In truth I think empathy probably provides some access to some of these on the room-occupants list, and that is the natural place for some of them (like op/deop/voice/devoice/kick).  But things like /invite and /whois etc. can be applied to users who are not in the current channel.  Others like /nick, obviously one could go change one's nick in the setup, disconnect, and reconnect...but that really isn't the point, is it?

> There is certainly a tension between the Telepathy design and the nature of
> common IRC clients. It would be nice to be able to have a Telepathy client that
> is also a comprehensive IRC client, but I don't think passing through protocol
> is the right way to do it.

I'd be happy if empathy implemented GUI versions of most of these commands.  Then if I was too lazy to go do it the GUI way, then that would be my fault and I'd still have a choice of other IRC clients.  What bothers me, I guess, is that I don't have a real choice between equals because telepathy doesn't implement these.  So the comparison between empathy and any-other-irc-client is like comparing apples to watermelons, and such a comparison then does a disservice to the (really good) idea behind empathy and telepathy.

If telepathy isn't going to pass / commands to the server, than maybe another option is for it not to send them to the channel as said messages?  Imagine someone joining a password-protected channel from another and doing "/join channelName password" accidentally...he has now told the original channel the password.  Well, that's only a thought to cope with the fact that anyone using IRC might expect it to respond to slash commands.

I you think it is better we can close this bug and I'll open one for the joining password-protected channels and other things as they occur to me.

Sorry for babbling on for so long,
-James

+1

*** Bug 533676 has been marked as a duplicate of this bug. ***

This has been reported against the Empathy package in Ubuntu as well: https://launchpad.net/bugs/397504

I'm using telepathy-idle 0.1.4 and Empathy 2.27.5, / commands don't get passed on to the channel but they result in an "Unsupported command" error displayed in the conversation window.  /me works as expected, but I haven't found any others that work.

Empathy doesn't always provide a full GUI replacement for the missing commands either, such as /join - there's a GUI to join a single channel, but no way to join multiple channels at once.

It's not obvious that to change the channel topic, you have to open a conversation with ChanServ and issue commands that way, rather than a simple /topic <topic>, and is there any way to do it in channels where ChanServ (or equivalent) isn't in the channel?  I still don't know if I have gotten ChanServ to give me +o in a channel, or if I can give other people +o or +v (or take them away) - the contact list doesn't give a way to differentiate normal users from those with voice from half-ops from ops, and there's no /whois to check.

It's not immediately obvious that you need to go to the main contact list and choose Chat -> New Conversation... just to get to users who aren't in a channel with you.  Like NickServ, or MemoServ, or possibly even ChanServ.  A /msg command would also make it faster to access these services.

Right-clicking on a user and choosing Information gives much less info than /whois <user>

I don't think there's any replacement for /kick or /ban. These are pretty much essentials if you're a channel operator and a troublesome user shows up.

I also don't think there's a replacement for /part. As for /quit, I can set a default quit message, but it's a real hassle to change it for just one time just to have to remember to change it back for the next time.

*** Bug 597358 has been marked as a duplicate of this bug. ***

Created attachment 145039 [details]
Patch for telepathy-idle 0.1.4 + empathy 2.28.0

The attached archive provides patches for basic IRC command functionalities for Empathy 2.28.0.

telepathy-idle must be patched separately.
My first patch anyways.

(patch not mine, from downstream https://bugs.edge.launchpad.net/ubuntu/+source/empathy/+bug/397504)

(In reply to comment #9)
> telepathy-idle must be patched separately.

Idle patches should be file on bugs.freedesktop.org.

(In reply to comment #9)
> Created an attachment (id=145039) [details]
> Patch for telepathy-idle 0.1.4 + empathy 2.28.0
> 
> The attached archive provides patches for basic IRC command functionalities for
> Empathy 2.28.0.
> 
> telepathy-idle must be patched separately.
> My first patch anyways.
> 
> (patch not mine, from downstream
> https://bugs.edge.launchpad.net/ubuntu/+source/empathy/+bug/397504)

Idle should not parse commands out of regular IMs you try to send. /msg and /join should be implemented in Empathy, using the normal Telepathy interfaces. if you want /quote cs lol to send the "cs lol" command, idle needs a separate interface for that.

Here is empathy patch for /topic /join and /query:

http://git.collabora.co.uk/?p=user/xclaesse/empathy.git;a=shortlog;h=refs/heads/irc-command

That branch now have /msg as well.

Created attachment 145940 [details] [review]
Fix topic not always shown, and add /topic command support.

Created attachment 145941 [details] [review]
Add support for /join command

Created attachment 145942 [details] [review]
Add support for /query command

Created attachment 145943 [details] [review]
Add support for /msg command

Created attachment 145944 [details] [review]
Refactor chat commands.

Comment on attachment 145940 [details] [review]
Fix topic not always shown, and add /topic command support.

>+				_("This conversation does not have topic"));
  Should be ``a topic''. Still seems a big clunky though, irssi says ``No topic set for X'', which might be better

>+		if (!(property->flags & TP_PROPERTY_FLAG_WRITE)) {
>+			empathy_chat_view_append_event (chat->view,
>+				_("You need to be a channel operator to do that"));

Not all protocols have a concept of channel operator or it's not actually necessary to be one. On irc permission to change the topic is seperate from being the operator for example. Probably better to just says ``You're not allowed to change the topic''

Comment on attachment 145943 [details] [review]
Add support for /msg command

>+	if (error != NULL) {
>+		empathy_chat_view_append_event (data->chat->view,
>+			_("Failed to msg contact"));
   Should be a better string ``Failed to send a message to X'' for example?

>+	tpchat = EMPATHY_TP_CHAT (
>+		empathy_dispatch_operation_get_channel_wrapper (dispatch));
>+
>+	if (empathy_dispatch_operation_claim (dispatch)) {
>+		EmpathyMessage *message;
>+		gchar *event;
>+
>+		message = empathy_message_new (data->msg);
>+		empathy_tp_chat_send (tpchat, message);
>+		g_object_unref (message);
>+
>+		event = g_strdup_printf (_("[%s]: %s"),
>+			empathy_tp_chat_get_id (tpchat),
>+			data->msg);
>+		empathy_chat_view_append_event (data->chat->view, event);
>+		g_free (event);
>+
>+		empathy_tp_chat_close (tpchat);
>+	}

So the chat is closed directly after sending the message, doesn't seem good for user feedback. Apparently X-Chat does it this way, but i'd guess it has some other way of showing you send a message. irssi just opens a new window when you send a message, but doesn't switch to it, which seems more sensible.

Comment on attachment 145944 [details] [review]
Refactor chat commands.

>+static void
>+chat_command_msg (EmpathyChat *chat,
>+		  const gchar *str)
>+{
>+	EmpathyChatPriv *priv = GET_PRIV (chat);
>+	TpConnection *connection;
>+	ChatCommandMsgData *data;
>+	gchar *id, *msg = NULL;
>+
>+	id = g_strdup (str);
>+	if (id != NULL) {
>+		msg = strchr (id, ' ');
>+		if (msg != NULL) {
>+			*msg = '\0';
>+			g_strstrip (++msg);
> 		}
>+	}

g_strsplit might be quite useful here..

> 
>-		/* FIXME: We should probably search in members alias. But this
>-		 * is enough for IRC */

Not a blocker, but please open a new bug to fix this. Especially since empathy autocompletes on aliases in chatroom, this is needed to make it actually work on say XMPP.. It should probably use longest prefix matching..

>+	if (EMP_STR_EMPTY (id) || EMP_STR_EMPTY (msg)) {
>+		empathy_chat_view_append_event (chat->view,
>+			_("Usage: /msg pseudo message"));

pseudo? You probably want to use <name> instead

>+typedef struct {
>+	const gchar *str;
>+	ChatCommandFunc func;
>+} ChatCommandItem;
>+
>+static ChatCommandItem commands[] = {
>+	{"/clear", chat_command_clear},
>+	{"/topic ", chat_command_topic},
>+	{"/join ", chat_command_join},
>+	{"/j ", chat_command_join},
>+	{"/query ", chat_command_query},
>+	{"/msg ", chat_command_msg},
>+	{NULL, NULL}
>+};

Add a boolean to indicate whether or not a command takes a argument, then you don't have to do the silly extra space and you can make sure that /clear and /clearmyface don't do the same thing :) Also a /help command would be good :)

>+	priv = GET_PRIV (chat);
>+
>+	chat_sent_message_add (chat, msg);
>+
>+	for (i = 0; commands[i].str != NULL; i++) {
>+		if (g_str_has_prefix (msg, commands[i].str)) {
>+			gchar *str;
>+
>+			str = g_strstrip (g_strdup (msg + strlen (commands[i].str)));
>+			commands[i].func (chat, str);
>+			g_free (str);
>+			return;
>+		}
>+	}

probably check if the first character is a / (maybe remove the / from the command list), only then do the prefix matching and if ti doesn't match throw up a help message ?

Created attachment 146221 [details] [review]
Add support for /help command and fix review comments

Currently 17 Empathy tickets are set as GNOME 2.30 blockers, hence mass-removing.
Guillaume: Please use normal Target Milestones instead. If you really think that this specific issue here is a 2.30 blocker then please restore the GNOME target and set corresponding importance values.

I updated my branch with more fixes. Review needed :)

+		for (end = text; *end != '\0' && !g_ascii_isspace (*end); end++);

I always perfer to use:
 for (badgers)
    /* do nothing */ ;

To make it very clear otherwise it's too easy to miss the ; at the end


You could avoid the rechecking of the prefix after chat_command_parse by checking before it if msg + 1 + strlen (prefix) is a whitespace. (not a merge blocker)

Fixed and merged. Thanks.

*** Bug 600582 has been marked as a duplicate of this bug. ***

*** Bug 601164 has been marked as a duplicate of this bug. ***

using empathy 2.29.3
/part says Unknown command, see /help for the available commands
and joining multi channels like /join #ubuntu,#ubuntu+1 gives: - Failed to join chatroom

other commands work fine.

Please open one bug per missing command. I opened bug #604347 and #604347 about the 2 bugs your mentionned.

Hi guys, is there any chance /list will be implemented in empathy, I think it may have been missed from the original description. 
A request for this was also filed in Launchpad at https://bugs.launchpad.net/ubuntu/+source/telepathy-idle/+bug/509802

Not while it's not implemented in telepathy-idle: http://bugs.freedesktop.org/show_bug.cgi?id=23005

I have both installed and cannot use this command. /join also does nothing, I have to manually select the room from the empathy menu. Regression?

/join is a regression which is already fixed in master. The fix will be included in the next release.

Ok, thank you :)