Quassel IRC

This is also related to BR #36 (where to display notices). The same problems apply when replaying the backlog as well - how should the backlog know, if we had a query buffer open for a particular nick, and otherwise, where should it be displayed?

This doesn't really apply to the question itself but I don't like this one:

For example, if I send /msg $nick $text, it should be sufficient to just display this in the current buffer.

I think, when I actually want to send a message to a specific target and don't want the message to be displayed, then it too should not be displayed in the current buffer. I tend to use my user authentication with the /msg command and like that it's not displayed or stored.

Regarding the subject:
I'd handle it simple: privmsgs should be displayed in the buffer identified by the sender(aka prefix) unless it's target is a channel.
That's the way it works for irssi and weechat. Not only do I have to say, that I find this quite convenient but I can't imagine an easy solution to determine wether it's only one line we're receiving or if it's about to become a real private conversation.
Ergo -> always open a querybuffer.

Another thought:

There are two active ways to initiate private messageing, /msg and /query.
Traditionally, /msg does not open a query buffer, while /query does. So the user can decide what he wants if he initiates a private chat.

Now for incoming messages: I think it's a good idea to use that information. So if I used /msg to send a privmsg to A, then replies by A should be displayed in the current buffer. If I used /query, they should arrive in the query buffer. For new contacts, a query buffer could be the default.

I think this solves a lot of the problems I see with "always open a query buffer": Often, I /msg bots to get some information, and I don't want to have a query open for their reply then. I also don't want to have that displayed in the status buffer, because I really hate the fact that in WeeChat I always have to switch my current buffer to read the reply.

I don't really like that Idea.

First of all this comes with quite a lot of technical difficulties:
1.) you say you want to use the information of how you initiated conntact (/msg -> don't open a buffer to display my message -> display reply in current buffer)
This means, that you have to store a List/Set of Users you contacted via message. When will this list be cleaned up? The next time you really use /query?

2.) to display the message in the current buffer you need to manipulate the incoming message: aka redirect the target. But what's the current buffer? The current buffer is indicated by one of the sychronized selection models in the client. The redirection has to take place in the core as the messages will be stored there.

To pick up your bot/auth case: yes I use /msg in that case too. But I prefer to get the answer of the bot in a separate buffer. Not only does it logically belong there, it's also the easiest way to get rid of that information. Close the Buffer. I wouldn't want to clutter up my regular chat with some auth stuff. Actually the client provides a convenient way to hide a seperate buffer (custom views).

Just to make sure: I think we all agree on the fact that it's a good Idea that /msg shouldn't open a buffer and /query should