Skip to content
This repository has been archived by the owner on Feb 10, 2024. It is now read-only.

Random highlights which don't match anything in "Extra words to highlight" #371

Open
Arnavion opened this issue Jan 11, 2013 · 13 comments
Open
Labels

Comments

@Arnavion
Copy link
Contributor

irc_extra_hilight = Arna,Arnav,Arny,Arnie,*Arnavion*,Arnavicon,Arniggervion,*navion*,Arnawion,AtashiCon,ARNAVION
irc_nick_hilight = 
irc_no_hilight = NickServ,ChanServ,InfoServ,N,Q,Quotes,Belfiore,Trivia,{Houki}

Examples of a message which highlighted me this morning:

<@gmaxwell> I _thought_ that if the binary was fully static it did manage to link it. Maybe I'm remembering it wrong.

Pasting the same message (via another client) doesn't highlight me again. In other words, this is non-deterministic and almost certainly a bug.


Edit: As it turns out, these phantom highlights only trigger for #bitcoin. The only thing I can think of that's special about that channel is that it's the first channel I (auto-)join in freenode, which itself is the second network I (auto-)connect to. None of the channels in the first network (Rizon) or any other channels in Freenode trigger these highlights.


Edit 2: Above confirmed. Now that I'm also on #gtk+ on GimpNet, this behavior only occurs in that channel. It seems this behavior happens on the first channel of the last network I joined.


Relevant code is in inbound.c (alert_match_word, alert_match_text) and util.c (match).

Possible fix is to replace the loony logic in those methods with GRegex.

Aside: GRegex was introduced in GLib 2.14, so bump up the requirement in configure.ac

@ghost ghost assigned Arnavion Jan 11, 2013
@prassel
Copy link

prassel commented Feb 4, 2013

merge? #327

@Arnavion
Copy link
Contributor Author

Arnavion commented Feb 5, 2013

What for? That bug and this one are not the same.

@TingPing
Copy link
Member

TingPing commented Feb 5, 2013

Once you convert this to regex maybe it could handle that better.

@RichardHitt
Copy link
Contributor

Since this issue is difficult to reproduce, I have added temporary code (#400) to inbound.c, outbound.c, inbound.h that records information (timestamp, text, from) for each time is_hilight()'s "if"-statement returns TRUE. It forms a GList of these triplets, whose count is constrained by global uint count371lim and initially 100.

To show the results at any time, type the command "/debug hilight" on any hexchat command line. Here's sample output from that command:
Debugging the hilight problem (issue 371) ---
(Each of the two strings is preceded and followed by the eyecatcher "---")
02/06/13 15:16:42 text:---testme there, rich3abcd--- from:---richtroye---
02/06/13 15:16:46 text:---testme there, rich3abcd--- from:---richtroye---
02/06/13 15:16:48 text:---testme there, rich3abcd--- from:---richtroye---
02/06/13 15:17:11 text:---testme there, rich3abcd--- from:---richtroye---
02/06/13 15:17:11 text:---testme there, rich3abcd--- from:---richtroye---
02/06/13 15:17:11 text:---testme there, rich3abcd--- from:---richtroye---
End of list

Please when you're running this code, be alert for perceived errors pertaining to this Issue. When you see one, run /debug hilight and copy-and-paste the results to a file. Write a note here about what you saw and include pertinent lines from that file.

@TingPing
Copy link
Member

TingPing commented Feb 7, 2013

@RichardHitt considering its temporary why would you make a pull request instead of just pointing us to the branch?

@Arnavion
Copy link
Contributor Author

Arnavion commented Feb 7, 2013

If that is the purpose you made that PR, I could've told you earlier it was unnecessary. I already have a highlight logging script which logs the same information.

Edit: Here's the script - https://raw.github.com/Arnavion/random/master/hexchat/highlight.pl

TingPing added a commit that referenced this issue Mar 27, 2013
For gregex mentioned in #371
@Arnavion
Copy link
Contributor Author

Arnavion commented Nov 3, 2013

Hasn't reprod in quite some time (atleast since 2.9.6). Closing.

@Arnavion Arnavion closed this as completed Nov 3, 2013
@Arnavion
Copy link
Contributor Author

Started happening again since this morning (two times in 12 hours) :|

@Arnavion Arnavion reopened this Nov 14, 2013
@whispy
Copy link

whispy commented Aug 14, 2014

This has just started happening to me. I ran /debug hilight, but it only listed the channels and servers I am in. I assume the temporary code @RichardHitt added has been long since removed.

This began after I tried adding a new highlight ('the bot died'): TW,whisper,the bot died,. It then kept happening after I removed the new highlight and went back to the highlights I originally had (TW,whisper,). I even removed everything from the highlight field, and then added back only the ones that I had prior to adding the new one, but it still highlighted random lines. If I delete everything from the field, then I don't get random highlights.

EDIT: Even removing all highlights, restarting the program, and then adding the highlights back again doesn't fix the problem. Still results in random highlights.

@whispy
Copy link

whispy commented Aug 14, 2014

Okay, fixed the problem by removing the trailing , from my highlights.

TW,whisper, = random highlights
TW,whisper = no random highlights

@mswietlik
Copy link

This happens to me in the latest release, with or without the trailing comma.

@faithlessfate
Copy link

Latest release, this is happening to me in all channels on all networks.

EDIT: In normal writing you tend to write spaces after commas. In the HL list there should be NO spaces. Removing them between my commas fixed the problem.

@ConnorKrammer
Copy link

I also encountered this issue. As per @faithlessfate's solution, stripping the whitespace around each term solved the issue.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Development

No branches or pull requests

8 participants