Default hilight doesn't match if row begins with bold

[irssibot]

• • • Issue #162 opened by @Daedalon

If a line in IRC begins with my nick, Irssi hilights it normally. If someone wants be sure to attract my attention, he might use bold control codes to make my nick more visible in the window. For example some trivia game bots do this.

The problem is that when a line starts with a bolded character, Irssi doesn't hilight the window even if the message then continues with my nick. Instead of doing this, the default nick-hilight should ignore all bold / underline / reverse / color control codes, as they don't change the fact that someone has written me a message and I want to know about such thing as soon as possible.

If I would dislike visibility control codes in general, I could always ignore them, but as they are handy time to time, in fact increasing the readability of many channels I'm on, I would only like to know when someone writes me a chanmsg and not let bold control code get in the way.

I believe that making this change wouldn't impair anyone's IRC experience, only improve.

[irssibot]

• • • Comment 213 by @Daedalon

It seems that also the tab-complete code improperly stops to function if the already-written part that user wants to be completed contains a bold or any other control code. And this is caseless, tab-complete doesn't only falsely read these characters but also stop the whole complete business when one is encountered.

Examples ( means bold control code and means tab being pressed):

[Users #channel] [Daedalon] [AFriend] -!- Irssi: #channel: Total of 2 nicks [#channel] AF

results with:

[#channel] AF

instead of this, which the user most probably wishes for:

[#channel] AFriend

This seems like reading control codes as being part of the string that the user wants tab-complete to search a match for, while the real string to be completed is AF and couldn't in the case of nick possibly contain any control codes. But, for channel topics, this is even weirder, as tab-complete does not read control codes wrong, it refuses to read anything with them:

-!- Daedalon changed the topic of #channel to: The topic

[#channel] /topic #channel T

results in

[#channel] /topic #channel The topic

while

-!- Daedalon changed the topic of #channel to: <b>The<b> topic

[#channel] /topic #channel

results oddly enough in

[#channel] /topic #channel

and not the one that is clearly being asked for,

[#channel] /topic #channel The topic

I wish these could be fixed soon, so I could do additional testing to spot any further bugs with control code handling in hilight, tab-complete and other possible places before version 0.8.10 is out for the masses.

[irssibot]

• • • Comment 218 by @coekie

I don't really agree with the original bugreport. It only hilights if the nick is the very first thing in the message, I don't think that adding exceptions to that is worth it. If you want your nick hilighted even when there's a in front, just /hilight nick, which still works.

But it might indeed be nicer to let "AF" complete (just like ",AF<tab" works

You say "/topic #channel T" completes, but afaik (and as far as I tested) it doesn't. ("/topic #channel " however does, and behaves like it should with )

[changing type to feature request]

[irssibot]

• • • Comment 226 by @Daedalon

I don't think that adding exceptions to that is worth it. If you want your nick hilighted even when there's a in front, just /hilight nick, which still works.

I have tried /hilight Mynick, but I left that as a try. Every day my awaylog had several lines of bots replying to !top commands in different channel, displaying my nick. I rarely miss anything that was targeted to me without additional /hilights, except for those times that my attention is really wanted and emphasized with bold.

I don't see any downsides in removing mIRC control characters from the message before matching it with the default hilighting message. In fact I don't see why this wasn't made the default behaviour in the first place, and it took me long to get to be really sure that this indeed was the case and my eyes weren't fooling me.

At least I would like an option to set this ignoring for control characters in the default hilight so that I'd notice when someone tries to reach me while using one, but my awaylog wouldn't be filled every night with messages containing my nick somewhere else than in the very beginning (control characters ignored).