/ignore <x> HILIGHTS doesnt work

[irssibot]

• • • Issue #754 opened by @CyberaX

Ignoring just HILIGHTS from any target, does not work, the hilight triggers regardless whether it be a channel or nick.

[irssibot]

• • • Comment 1205 by @coekie

Are you trying to add hilight exceptions using /ignore?

There is no way in irssi itself to add exceptions for hilights at the moment (and using /ignore for it wouldn't make sense). You can use the trigger.pl script as a workaround (see the examples in its docs).

Or are you really trying to ignore (hide) lines that match a hilight?

[irssibot]

• • • Comment 1206 by @CyberaX

I need to be able to set it so that for certain channels/nicknames hilights dont trigger. I've tried trigger.pl, but i could never get it to work properly.

Especially for bots, which happen to state my realname - i don't really want to be hilighted by them.

If ignoring just hilights from targets is not allowed, then the target needs to be removed from /help ignore and /ignore, so it errors when people try to use it.

[irssibot]

• • • Comment 1207 by @CyberaX

Ideally, you should be able to ignore or simply strip the level (HILIGHT), allthough i've not looked at the code, to see how pheasable either of these are.

/ignore [-strip?] ? should be able to simply drop any lines that trigger the ignore (or other targets for that matter?) similar to a normal ignore or even strip the level.

If ignoring hilights like this isn't supported, then at least some way to halt processing of hilights or strip the level if they match an exception, e.g. /hilight -except "x,y,z,#blah" ?

At the moment i dont have any anway to stop hilights triggering for a specific target, its the one thing that most

[irssibot]

• • • Comment 1208 by @CyberaX

• drives me crazy about irssi.

[irssibot]

• • • Comment 1221 by @pyropeter

I added the -invert switch that suppresses hilighting if the /hilight-entry matches a message.

http://gist.github.com/476285

Atm this only works with messages handled by sig_message_public in src/fe-common/core/fe-messages.c.

It suffers a lot from -priority not beeing implemented.

But this should be sufficent to block bitlbee from hilighting you at every jabber.org reconnect.

[irssibot]

• • • Comment 1224 by @coekie

Thanks for the patch, it's a start. But I'm not going to commit it until it is more complete, there's already enough confusing behaviour in /hilight.

To be consistent with /ignore, the option should probably be called -except.

For -line or -word hilights, the problem is that the exception could match in fe-messages, but not in hilight-text where the hilight we want to override is matched. Some ideas for how to make that work (other suggestions are welcome):

• set the NO_HILIGHT level on the message in fe-messages (but this wouldn't make it possible to properly use -priority like explained below)
• set the hilight_priority on the destination without hilighting it and making sure hilight-text handles that case correctly. But that feels a bit fragile / confusing to me.

• my suggestion in the first comment on bug 275: attach the hilight to the destination.

  -priority is implemented, but it is not used to choose which hilight matches a single message. It is used to let a newer hilight on a window that was already hilighted by a previous message override that hilight (That is most apparent if the hilights have different colors). And "/window goto active" (or active_window binding, alt-a by default) uses it to choose which window to switch to first. It would indeed be better if it used it to choose which hilight matches a single message too. But (until now) that's is only a minor problem (I can't even find an issue open for that yet).

For exceptions (if you don't set a priority on them) I'd expect an -except to "win" over another hilight. That way you don't need -priority to make -except work at all. So I see these as two separate (only partly overlapping) issues. But practically, it probably makes sense to implement them in one go :)

[irssibot]

• • • Comment 1229 by @pyropeter

1. Would it be possible to move the hilighting code in fe-messages to hilight-text?
2. Couldn't hilighting of current nickname be a "normal" hilight, like '-regex "^$N. "' ? This would simplify hilighting extremely and also add the feature to change the format of a nickname-hilight.
3. If attaching the hilight to TEXT_DEST_REC, shouldn't one also remove the variables hilight_priority, hilight_color (, flags?) to avoid redundancy? (This sounds like a lot of stupid work, so I better ask before doing it)

[irssibot]

• • • Comment 1254 by @pyropeter

This still bothers me, I am still willing to fix it, but I need your feedback.

[irssibot]

• • • Comment 1259 by @coekie

Sorry for the late reply. I hope it still bothers you enough :)

1. No, I don't think so. Because at hilight-text you A. can't do a -nick hilight because all you have is a blob of text; you don't know which part is the nick. To do that we'd need some special markers (using the irssi internal format stuff also used for colors) in text surrounding the nick, so it can be found back later to change its color. That would also mean dropping the feature of having separately configuratble hilight_* formats (but that's not a really big deal imo). So not entirely impossible but it does mean more changes... B. can't check -mask hilights anymore because you don't know who the message came from at that layer. Unless we add extra stuff to pass that around... C. You don't want everything in the line being printed to be checked for hilights. For example you don't want to hilight yourself every time you say something because the line contains your own nick. (That could be avoided by checking for the same marker as in A, but that makes it more complicated). Another example: some formats for messages contain the channel name, and you don't want a hilight on "irssi" to trigger every time someone says something in #irssi. (And we could solve that by having other markers saying which parts should be checked for hilights and which shouldn't... making it even more complicated).
2. That would also be a nice feature yes.
3. Correct