I was (still) playing around with $hotlink and it seems like $hotlink(match) removes the '`' characters as well as the '-' character when triggering on hotlink for a nickname on a channel.

As far as I understand $hotlink(word) returns the full word used to trigger the on hotlink event. (returns <@Wims> if hovering on <@Wims> triggers the on hotlink event)
But $hotlink(match) returns the part of the full word that was used for a comparison for known types. (returns Wims if hovering on <@Wims> triggers the on hotlink event)



Hovering the nickname "kikuchi`" on a channel, $hotlink(match) returns kikuchi while $hotlink(word) preserve the '`'.
This is wrong behavior in my opinion, $hotlink(match) shouldn't be removing characters which are allowed in a nickname.

TL;DR: $hotlink(match) does not preserve backtick (`) nor hyphen (-) valid nickname characters when $hotlink(match).type == nick, such that Raccoon` or Raccoon- becomes Raccoon

What's that for, are you suggesting the bug report has too many details?

I once suggested to add $dialog().ontop without much detail and apparently it wasn't clear enough what it was supposed to mean/do for someone of argv0's caliber when it should be quite obvious it would be (basically) related to if you used /dialog -o to set the dialog on top or not, so now it's better to be safe than sorry.

Also this post serves as a way to confirm the actual behavior of $hotlink with Khaled, some are as obvious as $dialog().ontop once you try them, but $hotlink(match) vs $hotlink(word) isn't so simple if you're not making the specific right tests.

$hotlink

It needed some clarity for fast readers. I couldn't follow your report at first as it danced around the point. Just helping you out so Khaled can lock on quickly.

I really need to work on my english!

Thanks for your bug report. This is by design and has been discussed before. The hotlink event extracts words from a line of text that that might use many different text formats and combinations of quotes, brackets, and so on, and these might enclose many different types of words. There is no way for the hotlink event to know exactly what type of word you are looking for or how far to strip certain combinations of enclosing characters, so it performs a generic extraction that works in most situations.

Ok. But if mIRC knows it's a nickname match, couldn't mIRC play it smart and only strips the necessary?

Where has this been discussed exactly?

I have to agree with Ouims on this. If $hotlink(match).type equals "nick", then mIRC knows that it's a nickname, it knows who the nickname belongs to, and it ought to return that nickname using whatever fashion that mIRC arrived at the knowledge that it's a nickname in the first place.

When I right-click on Raccoon` or Raccoon-, I don't want to /kick Raccoon. I want to kick the impostors.

Retracting from bug report as I can't actually reproduce Ouims's bug at this time.

Right, so Raccoon pointed out that actually this bug report is a bit invalid. My tests weren't correct, the '-' was not part of the nickname (I was hovering -nickname- from a displayed notice using mIRC default display), and the nickname with `, let's say X`, was not connected, but X was, and that's why mIRC reports that as the match.

So to conclude, what's really problematic now is that if you have X and [X] on a channel and you get both these words to trigger on hotlink, both $hotlink(match) will report X as the nickname, which I find incorrect but is still explained by what Khaled said.

Now why is that a problem (to me)? Well, because we would be happy to be able to hover <@nick> and be able to get 'nick' from it, easily, without doing string manipulation ourselves, which is what I thought was possible, but in fact it's much worse; $hotlink(match).type being 'nick' does not guarantee that you hovered a nickname in a channel, you actually have to do string manipulation on $hotlink(word) by yourself to remove all the character not valid in a nickname and then check that the nickname is on the channel. To me this makes $hotlink(match).type for nickname not so useful, to say the least.

It cannot, for two reasons: 1) it does not know it is searching for a nickname, and 2) lines do not contain metadata - they consist of plain text.


You will need to search the forums for it.

I couldn't find anything which discuss this on the forum using a 8 years range ($hotlink was added 6 years ago) on the word 'hotlink'.
I check the forum a lot and this is the kind of things I care about so I'd say I'd remember it if it had been discussed

Now, to clarify, none of what I said is true for connected nickname, if [X] and X are both connected, hovering [X] works correctly.

The problem is only when you hover [X], that [X] is not a connected nickname but that X is, this is where mIRC triggers on hotlink with $hotlink(match).type == nick and $hotlink(match) being X (I failed to realize this is what was happening in my first post with kikuchi` while kikuchi was connected, maroon's post also describe that).

But ok if this is by design well fine, but I'm practical, so I like to get 100% rather than 99%.

Thanks for your comments. If, at some point, I decide to rewrite the hotlink feature, I will take your suggestions into account.