Bug #90
Redirection of Certain IRC Commands
0%
Description
Under certain circumstances it's usefull to redirect a server msg to another target (mostly replace the server buffer as a targt)
For example if you start a Query with a User it's usefull to see the information whether or not he is online in that query buffer and not in the status buffer.
This results in two questions:
1.) where to display the message?
This seems to be already discussed. There are 3 usefull locations:
a) the statusbuffer
b) the currentbuffer
c) the buffer about which the message contains information.
All of these can be determined in the client, so this should be pretty straight forward. If you can think of any other location, please note it here.
2.) how to enable redirection?
I see 2 ways to enable that redirection:
a) add a separate field to Message which contains a possible redirection target.
b) always replace the original target with the intended buffer and set a flag to show that redirection has been enabled.
I think the second way is probably the best. The Client can then chose to use the redirected target, or display it in the current buffer or status buffer.
The only downside I see, is that the message is stored not at the target it was originally (by the irc server) intended. In my opinion this might only be of concern when backlog is when backlog is permanently deleted. In my opinion a minor detail.
Thoughts?
Related issues
History
#1 Updated by phon about 16 years ago
As these messages (which will be redirected) usually contain information about current events like WHOIS information or idle/away messages, I aggree that deleting those messages when deleting the (user) query shouldn't be a problem.
#2 Updated by EgS about 16 years ago
already done. -> close
#3 Updated by EgS about 16 years ago
So this has been implemented now. And new things come to my mind:
These client settings for redirection currently apply only to new messages (no backlog) and regardles of the message type.
Should there be different sets of settings for Notices and Errors like "no such nick or channel"?
What about backlog? Apply the same settings or introduce yet another set of settings?
Personally I think I'd like to have different sets, though I think this might become pretty confusing for regular users.
Please comment on this issue.
#4 Updated by Sputnick about 16 years ago
OK, after using this for quite a while, I have observed a couple of things:
- It is very annoying when every reconnect to a network opens a new buffer for the particular server we are in (if there is DNS RR).
- Enabling message display in the current buffer puts server messages in there too - very annoying again.
- It is not checked if we have already a query open for the peer.
From those observations, a couple ideas spring to mind:
- We need to distinguish between server and user notices. In almost all cases, I want server messages/notices in the status buffer. This is especially true for things like the MOTD. I don't want to have a "query buffer" for the particular server I connected to.
- On the other hand, notices by users I usually want to have in the current buffer, since often I do something like /msg someBot someCmd and then I don't want to switch to the status buffer to read the reply.
- When I'm in a query buffer with some user (bot), I definitely want the replys show up there. Currently, if I am in the query buffer with ChanServ, and type "help", the reply shows up in the status buffer even though I have "show in current buffer" enabled.
- As for storing in the backlog, I am not sure if we want to store NOTICEs from users/bots at all. Usually, this is stuff like help/identify/whatever, usually not interesting in the future and sometimes containing sensible data one does not want to have replayed. That said, I don't know if bots/services usually use NOTICE or PRIVMSG...
- I would probably try to distinguish between queries started by me with /msg and ones started with /query, and those initiated from another party. In particularly, if I /msg someone (again, usually a bot), I don't want to open a query buffer with him. On the other hand, if there already is a query, or if I openend one with /query, that should be used. If the other side /msgs me without me having a query buffer already, I am not sure what should happen. In case of notices, those should probably always go to the current buffer - nobody except bots uses NOTICE to initiate a query...
- For the same reasons as above, stuff I send with /msg explicitly should not go in the backlog at all. This is exactly what contains sensitive data, such as "/msg nickserv identify mycoolpassword"...
- That said, the core (currently) doesn't know how a message was sent, if it's from within a query buffer or if it was an explicit /msg. Maybe we should revive the /query command for that...
That's my random list of ideas/thoughts for now. Feel free to comment/discuss... :)