hexchat / hexchat

GTK+ IRC client
https://hexchat.github.io
GNU General Public License v2.0
3.05k stars 536 forks source link

Notice placement is wonky #978

Open TheWug opened 10 years ago

TheWug commented 10 years ago

Let's aggregate a list of gripes about Hexchat's placement of notices and maybe decide on some changes to its behavior. I'll start:

1) In AUTOMATIC mode, private notices from users will be placed in the front tab, except if you share a channel with the sender, in which case the notice will be placed in that channel instead (preferring the active channel if possible). This is especially annoying on freenode, where notices from chanserv will be eaten by an arbitrary channel if you issue a chanserv command in a channel without chanserv in it, but results in lost notices from other users as well.

Current placement rules, in order of precedence:

  1. All channel notices go to their channel tab.
  2. All server notices go to the server tab.
  3. If a dialog with the sender exists, the notice goes to that dialog tab.
  4. If the front tab is a channel that you and the sender share, it goes to the front tab.
  5. It goes to the channel you and the sender share that was joined most recently, if such a channel exists.
  6. If all else fails, it goes to the front tab for the network the sender is on.

Preferred placement rules:

  1. All channel notices go to their channel tab.
  2. All server notices go to the server tab.
  3. If a dialog with the sender exists, the notice goes to that dialog tab.
  4. If all else fails, it goes to the front tab for the network the sender is on.

2) I wish there was a way to more selectively control the behavior of certain types of notices, particularly server notices, especially in FRONT-TAB mode. They can be quite floody sometimes but are something of a necessary evil, and it would be nice to be able to confine them to the server tab even when in FRONT-TAB mode, rather like how they are seperated from other notices when in EXTRA-TAB mode.

Current placement rules, in order of precedence:

  1. All channel notices go to their channel tab.
  2. All other notices go to the front tab.

Preferred behavior:

  1. All channel notices go to their channel tab.
  2. All server notices go to the server tab.
  3. All other notices go to the front tab.

3) Your choice of notice placement does not affect where channel notices are put, HexChat will always put them in the channel they were sent to. Maybe channel notice placement should be configurable too?

TingPing commented 10 years ago

The current behavior is documented as such:

  1. In a query window you have with that user
  2. In the front tab, if the tab is a channel, the other user is on that channel, and you are on the correct network
  3. In the last joined channel you have in common with the other user
  4. The current tab, if you are on the same network
  5. The last tab you looked at that shares the correct network with the other user

In AUTOMATIC mode, private notices from users will be placed in the front tab,

According to the docs that should not be true, so perhaps that is a "bug".

My proposal is to modify rule 2 to include the special case of chanserv which is the most common complain.

New behavior: If the notice is a server notice, put it in the server tab.

I thought that was how it currently behaved, and agree that's how they should.

HexChat will always put them in the channel they were sent to.

So always in front you mean. Unless its a channel notice then yes I agree.

I think you need to clarify a bit on type of notices. There are Server notices, Channel notices, and User notices right?

Server notices:

  1. Always go to server tab.

Channel notices:

  1. Always go to channel tab.

User notices:

  1. Always go to dialog if exists
  2. Go to front if
    • from chanserv
    • both users in channel
  3. Shared tab if sender is only in 1 channel with you (maybe?)
  4. front tab if same network
  5. front tab of other network
TheWug commented 10 years ago

I didn't mention this earlier and should have, but the behavior for notices on multiple networks is totally sane so I left out inter-network conditions from my analysis.

In AUTOMATIC mode, private notices from users will be placed in the front tab, except if you share a channel with the sender

I phrased the rules weirdly, sorry about that. I believe HexChat is handling them exactly as is documented. More to my point is that I don't see why there are so many rules about how notices are handled. In particular, most people probably won't remember the order they joined their channels so I'm not really sure how that helps them, especially because it looks like (per the documented strategy) the placement of notices can change without any intervention from HexChat's user (i.e. if the sender joins another channel that you joined more recently, their notices will suddenly be delivered to that channel instead).

Furthermore, ChanServ is not the only service whose notices get eaten. Atheme can be configured to log to a channel, and in this configuration all services users will join this channel. If you are in this channel (maybe because of IRC operator duties), it will eat notices from all services users, not just ChanServ.

...notices sent to channels are put, HexChat will always put them in the channel they were sent to.

Yeah, that statement was exclusively about channel notices.

I'll go through and amend my issue with some more standardized terminology since it seems to have a high potential for miscommunication.

TingPing commented 10 years ago

most people probably won't remember the order they joined their channels so I'm not really sure how that helps them

Totally agree, I think that single rule is the main issue.

ChanServ is not the only service whose notices get eaten

What other services? We can't shove everything in front.

TheWug commented 10 years ago

What other services?

The list of services users is network-specific, but will typically include at least NickServ and OperServ. The full list of some recent but not-quite-up-to-date version of Atheme is ALIS, BotServ, ChanServ, GameServ, Global, GroupServ, HelpServ, HostServ, InfoServ, MemoServ, NickServ, OperServ, RPGServ, SaslServ, and StatServ. If you really want to handle every edge case things get even more complicated because Atheme will let you name services users to any valid nickname, and in later versions of Atheme, BotServ bots will encounter the same problem.

We can't shove everything in front.

Why not though? NOTICEs aren't supposed to have more context than PRIVMSGs, so going out of our way to hunt down context for them seems unreasonable. Queries with users are overriding contextual magnets, so placing incoming NOTICEs there (if they already exist) does make sense, but otherwise the sensible thing to is to organize them by their function (since channel notices and server notices also have obvious context) and just drop any remaining ones (user notices for users without any query windows open) into the front tab.

Arguments about context aside, the most common use of NOTICEs (as well as the use recommended by the RFC) is communication with bots (including all services bots) so it's probably sensible to optimize their handling for such interactions (i.e. notices from users should go to a query tab if one exists, and the front tab otherwise).

Remember that we're not mixing networks. Showing notices from one network in another is senseless, and I am implicitly honoring all network boundries in my descriptions.

TheWug commented 10 years ago

You mentioned on IRC (posting here for posterity) that the best way to go about doing this to ensure consistent behavior might be to drop _find_session_fromnick() entirely, in favor of the simpler behavior of _finddialog(). In an experimental change to notice placement, I used exactly this substitution, and it provides the expected behavior so it might be that we can simply replace all instances of one with the other and be done with it.

caktux commented 9 years ago

Would love to see this fixed, coming from Textual this got me quite puzzled as it's handled quite simply: new tabs get opened with users, so ChanServ notices just open a new tab if there is none instead of searching left and right where to put them, which also solves interactions with any notice-sending bots.

Mikaela commented 9 years ago

Does HexChat have an option for opening a query every time private notice (not statusnotice) is received? WeeChat allows that and I find it very helpful with finding notices.

On services, WeeChat's otr.py understands the following as services:

I hope this helps.

MrGadget1024 commented 7 years ago

ChanServ has an EntryMsg feature for channels that's intended to send 1 or more notices to the user when they join that specific channel. These really should appear in the channel they are meant for. In automatic or front mode they go to the server tab, along with a lot of other msgs, so they're lost, especially when one has a several auto-join channels for a given network.

rain-1 commented 6 years ago

when I do /msg chanserv access #channel list the answer is posted in (what seems to be) a random IRC channel.

It takes me a while to find the response, I have to check through all the channels I'm in that have had activity recently.

Is there any solution for this?

EDIT: Preferences > Channel Switcher > Placement of notices: In an extra tab