After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 724592 - /msg NickServ <commands> fail with - Unknown command try /HELP
/msg NickServ <commands> fail with - Unknown command try /HELP
Status: RESOLVED FIXED
Product: polari
Classification: Applications
Component: general
3.11.x
Other Linux
: Normal normal
: ---
Assigned To: Polari maintainers
Polari maintainers
Depends on:
Blocks:
 
 
Reported: 2014-02-17 23:54 UTC by Asif Ali Rizvan
Modified: 2016-01-29 09:03 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
ircParser: Support for /msg command in entry area (7.39 KB, patch)
2015-06-12 11:22 UTC, Bastian Ilsø
none Details | Review
chatroomManager: Don't set active room in handlechannels function (1009 bytes, patch)
2016-01-26 07:54 UTC, Kunaal Jain
none Details | Review
app: Add optional callback parameter to request channel (5.18 KB, patch)
2016-01-26 07:55 UTC, Kunaal Jain
none Details | Review
app: Change message user signal to query user signal (4.07 KB, patch)
2016-01-26 07:55 UTC, Kunaal Jain
none Details | Review
ircParser: Support for /msg command in entry area (5.45 KB, patch)
2016-01-26 07:59 UTC, Kunaal Jain
none Details | Review
app: Add optional callback parameter to request channel (3.21 KB, patch)
2016-01-29 05:56 UTC, Kunaal Jain
none Details | Review
ircParser: Support for /msg command in entry area (6.58 KB, patch)
2016-01-29 05:57 UTC, Kunaal Jain
committed Details | Review
app: Add optional callback parameter to request channel (2.86 KB, patch)
2016-01-29 06:02 UTC, Kunaal Jain
committed Details | Review

Description Asif Ali Rizvan 2014-02-17 23:54:38 UTC
why is polari not working with /msg NickServ on irc.freenode.net?

try this:
/msg NickServ help commands 



thanks.
Comment 1 Florian Müllner 2014-02-18 21:27:45 UTC
(In reply to comment #0)
> why is polari not working with /msg NickServ on irc.freenode.net?

Because /msg hasn't been implemented yet :-)


> try this:
> /msg NickServ help commands 

For now, you can do
 /query NickServ
 help commands
Comment 2 Quentin Dufour 2014-03-16 12:44:07 UTC
Does not work for Quakenet and the Q bot which needs to execute :
/msg Q@CServe.quakenet.org AUTH username password
also tried with :
/query Q@CServe.quakenet.org AUTH username password

(tried on irssi and it worked)

Today, I didn't found any solution to auth on Quakenet....
Comment 3 Bastian Ilsø 2015-06-12 11:22:24 UTC
Created attachment 305130 [details] [review]
ircParser: Support for /msg command in entry area

Attached patch adds basic support for /msg. What do you think of the approach?

A thing which might be nice to also support could be to have multiple recipients by fx entering "/msg john,paula,nick this is text".
Comment 4 Florian Müllner 2015-07-29 20:01:54 UTC
(In reply to Bastian Ilsø from comment #3)
> Attached patch adds basic support for /msg. What do you think of the
> approach?

Not a huge fan. Traditionally, "/query user" is used to open a conversation with user, and "/msg user foo bar baz" to send a one-off message to user - I don't think dumping the private message into the active channel as I've seen in some UIs works very well either, but I'd expect "/msg" to at least not focus the new conversation.
(I'm also not too convinced about adding "random" parameters to requestChannel() - a more generic approach could be to take an optional callback parameter that's called with the newly created channel or null in case of an error)


> A thing which might be nice to also support could be to have multiple
> recipients by fx entering "/msg john,paula,nick this is text".

How useful is this though? I can think of use cases, but it's not really something I've ever missed. Also, I'm not aware of any IRC client (either graphical or text) that does this, so it'd probably end up as Easter egg anyway ...
Comment 5 Federico Bruni 2015-09-27 13:25:18 UTC
Recently I spent a day trying to figure out how to register a nick to Freenode (as I had to join a channel which requires registered nicknames) because neither Empathy nor Polari had a /msg command, command suggested by freenode to send password and email for an account. /privmsg didn't work either.

Eventually someone recommended to use irssi and I managed to do it.

I'm surprised that this basic feature is not supported by these two linux clients. I've surely missed something, right?

Thanks for this nice app
Comment 6 Berend De Schouwer 2015-12-09 08:43:04 UTC
Unless I'm mistaken, empathy used to have a /msg command.  It seems to have swapped to polari as a client recently.
Comment 7 Michael Catanzaro 2015-12-22 00:17:14 UTC
(In reply to Berend De Schouwer from comment #6)
> Unless I'm mistaken, empathy used to have a /msg command.  It seems to have
> swapped to polari as a client recently.

It still does, I used it today. It might have been implemented within the last couple of years.
Comment 8 Kunaal Jain 2016-01-17 01:08:34 UTC
Florian, Bastian, what do you think would be the best approach to handle this? \msg foo hi send foo hi and that's it?
Comment 9 Bastian Ilsø 2016-01-17 12:24:17 UTC
The command should be used like this:
/msg <username> <message>

As florian wrote in comment 4 it should send a one-off message to user. by "one-off" my understanding is that the message is sent but without opening and focusing any private messaging window.
Comment 10 Florian Müllner 2016-01-19 17:53:09 UTC
(In reply to Bastian Ilsø from comment #9)
> As florian wrote in comment 4 it should send a one-off message to user. by
> "one-off" my understanding is that the message is sent but without opening
> and focusing any private messaging window.

Not opening the conversation window is kinda hard. I think not focusing it is good enough.
Comment 11 Kunaal Jain 2016-01-26 07:54:40 UTC
Created attachment 319725 [details] [review]
chatroomManager: Don't set active room in handlechannels function

We already set active room when joining a room, don't set
active room again in handlechannels
Comment 12 Kunaal Jain 2016-01-26 07:55:20 UTC
Created attachment 319726 [details] [review]
app: Add optional callback parameter to request channel

Add optional callback paramter with channel id
to request channel function to get the newly created
channel. Also use ensure_and_observe channel to get
the channel
Comment 13 Kunaal Jain 2016-01-26 07:55:42 UTC
Created attachment 319727 [details] [review]
app: Change message user signal to query user signal

Change name of message user signal for query
command to query user signal in functions.
We will be using message user signal for message
command soon.
Comment 14 Kunaal Jain 2016-01-26 07:59:02 UTC
Created attachment 319728 [details] [review]
ircParser: Support for /msg command in entry area

Adds support for /msg command which sends "one-off"
message to user without focussing on the coversation
window
Comment 15 Florian Müllner 2016-01-27 00:11:50 UTC
Review of attachment 319725 [details] [review]:

No. When telepathy tells us to present a channel, we should do that. Setting the active channel on 'join' for channels we request ourselves is just a shortcut to make the interface more responsive, it's not an excuse for ignoring external channels (for example the user clicking on a chat notification in gnome-shell to present it in polari)
Comment 16 Florian Müllner 2016-01-27 00:11:58 UTC
Review of attachment 319726 [details] [review]:

::: src/application.js
@@ +277,3 @@
         this._pendingRequests[roomId] = requestData;
 
+        this._ensureChannel(requestData, callback);

You should just save callback in requestData instead of modifying every function involved

@@ +311,3 @@
+            let channel = req.ensure_and_observe_channel_finish(res);
+            if (callback)
+                callback(channel);

I don't like how the error handling meant for channel creation now applies to callback() as well - I'd prefer:

 let account = req.account;
 let channel = null;

 try {
    channel = req.ensure_and_observe_channel_finish(res);
 } catch (...)
 }

 if (requestData.callback)
     requestData.callback(channel);

(this means not calling the callback when we get disconnected due to a network failure, but that's not less random than ignoring the callback on cancel - considering that the latter patch doesn't actually handle the error case, I'd consider changing the condition to "requestData.callback && channel")

@@ +350,3 @@
         let [accountPath, channelName, time] = parameter.deep_unpack();
         this._requestChannel(accountPath, Tp.HandleType.ROOM,
+                             channelName, time, null);

Just don't set callback, and it'll be undefined

@@ +360,3 @@
         let [accountPath, contactName, time] = parameter.deep_unpack();
         this._requestChannel(accountPath, Tp.HandleType.CONTACT,
+                             contactName, time, null);

Dto.
Comment 17 Florian Müllner 2016-01-27 00:12:02 UTC
Review of attachment 319727 [details] [review]:

You are changing an action name and a method - no signal involved anywhere ;-)

Also note that 'message-user' is named after the menu item in the (+) menu, not the /command. It's probably less invasive to just add 'ms' to the existing signature (if that works with GApplication, never tried it - otherwise could take the empty string '' to mean "no message") instead of copying action and methods
Comment 18 Florian Müllner 2016-01-27 00:12:11 UTC
Review of attachment 319728 [details] [review]:

Nit: "coversation" in commit message

::: src/application.js
@@ +368,3 @@
+    _sendMessage: function(channel, message) {
+        let TpMessage = Tp.ClientMessage.new_text( Tp.ChannelTextMessageType.NORMAL,
+	                                               message);

Style nits: no space after '(', messed up indentation

::: src/chatroomManager.js
@@ +201,3 @@
+
+        let room = this._ensureRoom(account, channelName, Tp.HandleType.CONTACT);
+        let [present, ] = Tp.user_action_time_should_present(time);

Unused

::: src/ircParser.js
@@ +189,3 @@
+                                                   nick,
+                                                   message,
+                                                   Utils.getTpEventTime() ]));

You should use Tp.USER_ACTION_TIME_NOT_USER_ACTION to indicate that the channel should not be presented
Comment 19 Kunaal Jain 2016-01-29 05:56:08 UTC
Created attachment 320000 [details] [review]
app: Add optional callback parameter to request channel

Add optional callback paramter to request channel function
to get the newly created channel. Also use ensure_and_observe_channel
function to get the channel as return value.
Comment 20 Kunaal Jain 2016-01-29 05:57:04 UTC
Created attachment 320001 [details] [review]
ircParser: Support for /msg command in entry area

Adds support for /msg command which sends "one-off"
message to user without focussing on the conversation
window.
Comment 21 Kunaal Jain 2016-01-29 06:02:38 UTC
Created attachment 320002 [details] [review]
app: Add optional callback parameter to request channel

Add optional callback paramter to request channel function
to get the newly created channel. Also use ensure_and_observe_channel
function to get the channel as return value.
Comment 22 Kunaal Jain 2016-01-29 06:05:11 UTC
(In reply to Florian Müllner from comment #16)
> Review of attachment 319726 [details] [review] [review]:
>  try {
>     channel = req.ensure_and_observe_channel_finish(res);
>  } catch (...)
>  }
> 
>  if (requestData.callback)
>      requestData.callback(channel);
> 
> (this means not calling the callback when we get disconnected due to a
> network failure, but that's not less random than ignoring the callback on
> cancel - considering that the latter patch doesn't actually handle the error
> case, I'd consider changing the condition to "requestData.callback &&
> channel")
> 

Checking for channel!=null in latter patch. Perhaps in future we might want to handle the error cases and propagate them to user?
Comment 23 Florian Müllner 2016-01-29 07:58:59 UTC
Review of attachment 320002 [details] [review]:

LGTM
Comment 24 Florian Müllner 2016-01-29 07:59:27 UTC
Review of attachment 320001 [details] [review]:

Yup
Comment 25 Kunaal Jain 2016-01-29 08:24:39 UTC
Review of attachment 320001 [details] [review]:

Pushed with commit 687614e5
Comment 26 Kunaal Jain 2016-01-29 08:25:12 UTC
Review of attachment 320002 [details] [review]:

Pushed with commit 7a2bfb3e