Irssi core bugs

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?

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.

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?] <x> <level>? 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" <trigger> ?

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

* drives me crazy about irssi.

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.

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 :)

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)