Decide when to open a query, and when to display a privmsg directly in the current buffer
Currently, all privmsgs received from or sent to another user will open a query buffer. However, this might not always be the right thing to do. For example, if I send /msg $nick $text, it should be sufficient to just display this in the current buffer. On the other hand, /query $nick [$text] stringly indicates, that I DO want to open a query buffer for this user.
Unfortunately, we don't have this distinction for incoming messages. So we have two possiblities, if no query buffer is already open: Display incoming messages in the current buffer (but of course, if we open a query buffer later, these messages will be part of its backlog), or always open a query buffer.
#2 Updated by EgS about 13 years ago
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.
#3 Updated by Sputnick over 12 years ago
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.
#4 Updated by EgS over 12 years ago
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
#6 Updated by EgS over 11 years ago
- Status changed from Feedback to Resolved
- Assignee set to EgS
- Target version set to 0.4.0
- % Done changed from 0 to 100
- Version set to 0.3.1+
Since there are now multiple ways to redirect messages, I don't think this is a real issue any longer.
Therefore I'm closing this bug.