/msg should open a new window with the user it is messaging

[YafahEdelman]

This would save people a lot of trouble as mean default to /msg instead of /query and this way they could see what they sent a user after sending it.

[AlMcKinlay]

So, #214 brought this up, and it was agreed that "/msg" should not open a query window.

However, it was noticed that the message just sort of ... disappears. We don't see it anywhere. It's also important to note that if someone replies to that (or just "/msg"s us), we will get a query window. So...this is the only case where messages don't go into a query window.

I think it would probably be worth just opening up the window anyway. Thoughts, others.?

[MaxLeiter]

Agree with @YaManicKill - a window should open when you message someone, and that's what IRCCloud and other clients do.

[daGrevis]

Agreed. It should open a new window.

[astorije]

@xPaw mentioned that this gets tricky for channels. So when messaging someone, we agree that it should open a window. But should this behavior happen regardless of type (person or channel), or for people only?

[MaxLeiter]

Regardless of type imo

[xPaw]

@MaxLeiter opening a window without joining a channel will be quite an odd experience.

[astorije]

@xPaw, I agree. Is it a reasonable thing to do than auto-joining a channel when messaging it and opening the window? If not then I think this should apply when messaging individual people only.

Open to suggestions.

[xPaw]

It is unreasonable to join the channel when you just send a message.

[astorije]

Why is that, @xPaw? I don't disagree at all, but right now it's just a feeling on my end and that's not enough to be objective :)

So it looks like we are heading towards opening windows when messaging people only.
How do other "modern" clients behave when it comes to messaging without being in the channel?

[dgw]

To answer your question about other clients' behavior, @astorije, I just did /msg #channel test in Textual (with #channel being detached in ZNC, so the network thinks I'm in it and will let me send even though mode +n is on), then checked the log file. Textual didn't open anything new, but my message and my bot's response were in the log.

So I guess the answer is probably that other "modern" clients send the message and forget about it. 😁

[astorije]

Thanks for the feedback, @dgw.

This comforts me for the following solution, at least for now:

• When /msg-ing a user, if the window is not open yet, open it
• When /msg-ing a channel I didn't join yet, keep the current behavior: message gets sent but I get no feedback

I suggest we keep this thread for when messaging a user, and deal with channels in a different issue later if necessary.

Does this make sense? 👍 or 👎 with this solution for messaging users?

[AlMcKinlay]

Sounds fine to me 👍

On Wed, 7 Sep 2016, 07:08 Jérémie Astori, notifications@github.com wrote:

Thanks for the feedback, @dgw https://github.com/dgw.

This comforts me for the following solution, at least for now:

• When /msg-ing a user, if the window is not open yet, open it
• When /msg-ing a channel I didn't join yet, keep the current
  behavior: message gets sent but I get no feedback

I suggest we keep this thread for when messaging a user, and deal with
channels in a different issue later if necessary.

Does this make sense? 👍 or 👎 with this solution for messaging users?

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#590 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACD_4eO2FlILyzkp9GFe_EWYQYAT7p_Vks5qnlTqgaJpZM4JzzSH
.

[jlu5]

On most clients I've seen (hexchat, weechat, iris, kiwiirc) /msg never automatically opens a query window. Instead the client just displays a receipt of what was sent (e.g. >nick< hello world in the current window). Automatic query windows would be counterintuitive IMO for things like services, as leaving a window open after messaging them isn't really helpful in the long run.

[dgw]

@glolol The Lounge could maintain a list of services nicks that wouldn't open a window…but really, users shouldn't be using /msg NickServ etc. on most networks, because aliases like /ns exist to obviate the possibility of accidentally messaging a real user when services are down.

[ghost]

This should absolutely be a thing. Either display it wherever you sent it from or open a new tab, but it definitely should be displayed (and logged!) alongside the answer.

#1391

[Jay2k1]

I want to express that I am strongly against having /msg open a query window -- if I want to do that, I use /query. I do send bot commands a lot though, where answers are mostly being sent as notice. If this is being made a thing, I'd welcome if it was optional.

There's no question though that what you send as /msg should be both visible and logged.

[AlMcKinlay]

I want to express that I am strongly against having /msg open a query window

There's no question though that what you send as /msg should be both visible and logged.

Well, the logging is simple, obviously, we'll just log it as normal. But here's a question, if you don't want it to open a query window, what should it do? Where should it show the message?

If this is being made a thing, I'd welcome if it was optional.

Oh goodness, no. This is such a niche option.

[Jay2k1]

But here's a question, if you don't want it to open a query window, what should it do? Where should it show the message?

In your active window, like /notice does. It is then debatable if that should always be the case, or only if there is not already an open query window for the target.

[astorije]

Posting a message in the active window (channel, for example) when it's not actually sent that channel is the most disturbing thing a user can expect. In particular when sending something sensitive, the last thing we should do is having it displayed amidst messages of a public place.

It seems very reasonable to me that both /query and /msg should open a window with your message on it. It's like common expectation with a chat application like @YaManicKill said here.

[Jay2k1]

Well, one of the world's most popular IRC clients (or at least what used to be) that I have used more than ten years seems to disagree.

And it makes sense. "msg" sends a (single) message, "query" starts a query, i.e. a private conversation.

The webchat used by some IRC networks, including freenode, (qwebirc, isn't it?), does it like that too:

I like it to send single messages, mostly to bots:

Also think /msg chanserv op #channel or something. You just issue a command, you don't actually want to start a conversation. Yet if you make /msg behave like /query, you'll always have the additional step of closing a query window. I find that quite annoying.

[astorije]

Well, one of the world's most popular IRC clients (or at least what used to be) that I have used more than ten years seems to disagree.

I understand, but this is not an argument we have lived by, fortunately. 10 years ago, we were doing very different things UX-wise, things we would never do anymore.
And if we think like this, then a client that doesn't disconnect you when you exit it, or a client that's entirely web-based, these were things fairly different from most popular IRC clients, and yet I'd argue these are some of the strongest features of The Lounge :)

I stand by my position though, sending a message to a given recipient, and seeing that message displayed in another window, like a channel, is just a no-go and an unnecessary panic.
In fact, I used to provide support for non IT people using IRC as part of an organization, and they were often alarmed by things showing in the wrong channel, thinking everyone could see it.

"msg" sends a (single) message, "query" starts a query, i.e. a private conversation.

If I read this picture by the letter, then /msg should not display anything. To me it's either that or displaying in the recipient window.
And honestly, separate /query and /msg do not make sense in the modern chat world anymore. It's very much an IRC thing. /query itself does not even make sense to me. What am I querying? Why does querying opens a window and messaging doesn't? Again, IRC arcane.
It would make complete sense to have them both do the same thing and be aliases. If you don't want the window, just close it. After all, if a bot answers you, you'll be happy to have the message you sent showing up on top of its response.

Also think /msg chanserv op #channel or something. You just issue a command, you don't actually want to start a conversation.

Unless we define hardcoded chatbot names for things like ChanServ, there is no way to make the distinction between a message-to-bot command and a message using the syntax you gave, from our perspective. Using /cs or native /<cmd> commands (when available) is more approachable.

[Jay2k1]

And if we think like this, then a client that doesn't disconnect you when you exit it, or a client that's entirely web-based, these were things fairly different from most popular IRC clients

Well, I guess using a bouncer or screen+irssi has been around for a very long time too. And as for the web, I'm not sure you could even do such a thing with the web technologies we had back then, but that's not the point here. There's no doubt that The Lounge with its features is a great thing.

I stand by my position though, sending a message to a given recipient, and seeing that message displayed in another window, like a channel, is just a no-go and an unnecessary panic.

Like so?

I could imagine changing that "Notice:" to "Private:" or "Msg:" or so for /msg. That would, in fact, be my suggestion how to deal with /msg, at least if there's not already a query window open for the target.

To be honest, I am more confused if I send something and don't see it. Yes, the way you propose would open a query window, but that might not be so obvious to some, and I seriously hope we're not talking about the new window opening in the foreground.

And honestly, separate /query and /msg do not make sense in the modern chat world anymore. It's very much an IRC thing.

This is indeed an IRC thing, and The Lounge is an IRC client, it's not Skype or Discord or Slack or WhatsApp. And I don't see how this "doesn't make sense anymore", it makes as much sense as it always did: A lot for some, not so much for some others.

If you don't want the window, just close it. After all, if a bot answers you, you'll be happy to have the message you sent showing up on top of its response.

As I already said, for someone who often interacts with bots, that quickly becomes very annoying. Oh and you are right about that last part.

Unless we define hardcoded chatbot names for things like ChanServ, there is no way to make the distinction between a message-to-bot command and a message using the syntax you gave, from our perspective.

Which is exactly why I want to have (keep!) a command to send messages like this, because I know who's a bot and who is not. And I am (of course) not only talking about chanserv and nickserv. Not every network has them, and there's a lot more to it than just official service bots. IRC games with bots are also a thing, just like "handy" bots like Wendy or lounge-bot, so using /cs etc. is really not an alternative.

Excuse me being so stubborn on this, but I really dislike when developers take away functionality from products just to make them more appealing to the masses. I'd have suggested to make an option for this earlier already, something like this:

...but I'm sure the answer would be that Lounge should be simple and too many settings would be too overwhelming and so on. Please correct me if I am wrong.

[iiiGerardoiii]

The way Textual handles this is quite nice imo:

/msg-ing a user opens a new window and /smsg-ing a user shows the sent message on the current window

More info on this: https://help.codeux.com/textual/Command-Reference.kb#cr=smsg

[xPaw]

This issue was mildly derailed so I'm gonna close it.

Current behaviour: Doing /msg user message opens a new query and puts the sent message in there.

[xPaw]

Turns out that was ZNC behaviour, lounge just eats the message.

[richrd]

So, keep the current behavior but add messages sent with /msg to history so that they are visible when opening a query?

[autra]

So, keep the current behavior but add messages sent with /msg to history so that they are visible when opening a query?

I'm more in favor of the "don't open a window when /msg", but yes, this would be very good. (Consistent with what weechat is doing for instance).

Also, maybe opening a window without focusing it could be a good middle-ground.

[dgw]

I've been uprooted from my normal setup (TL behind ZNC, with ZNC handling logging) and am using just TL 4.3.0 temporarily.

I was shocked to note that TL still "just eats the message" if I initiate a /msg to some other user, without even logging it. This first time it happened, I wasn't even sure my message had been sent until the other user woke up (I assume) and replied.

Do whatever y'all want re: /msg opening a new window, but let's please recognize the bug in logging. It simply shouldn't be possible for any message to just bypass the logs and never get saved, if logging is turned on. Users like me will continue to distrust TL's logging features if they demonstrate unreliability.

Maybe I should open a separate issue specifically about the hole in logging?