Forums Bug Reports mirc 7.25 &localchannelname

mirc 7.25 &localchannelname will not join on doubleclick

for example a bot invites you to &localchannelname you can't hit the invite notice channel name &localchannel to have the client join the channel. a /join &localchannelname works. when you hover over a local channel name the cursor does not change to the pointed finger hand symbol.

.256.256) invites you to join #channel
not &channel

i invited myself and i am able to see the hand cursor over the #channel invited to.

You can add your own hotlink behaviour for &chans.



Only Khaled can confirm, but I'm pretty sure the linking of &channels was removed because of confusion with user and channel modes, and the fact that &channels tend to represent an extremely small (and ever decreasing) portion of network channels. Messaging somebody a &channel link typically doesn't even make sense on many networks, as there is a good chance the users won't end up in the same channel (due to the server-specific behaviour of &channels), so I can't even imagine how often &channels are shared in public, let alone used in private. Fortunately if you do need it, it's pretty easy to add back via the above script.

it is a server (network) channel with a server bot that invites upon opering up. I don't see removal of the ability to link as other than an unintended consequence of working on the hotlink issues. (hope so at least)

I'm not denying that your usage is legitimate, I'm merely pointing out that it's an extremely niche feature of the IRC protocol that really is not often used. In fact, I would bet there are more networks with & being used widely as a usermode (halfop) than there are ones with more than a handful of populated &channels. There is a lot of potential confusion there. When a user is on a channel, &nick would have to hotlink a nickname, but once they leave it would hotlink a channel. Similarly, &text will always hotlink a nickname that shares the channel, which can confuse users who think &text will hotlink a channel. This problem isn't specific to &, it's also a problem for +, %, etc. And there are networks out there with those prefixes for channels, which would only lead to more confusion if mIRC were to hotlink channels with every prefix.

That's why it doesn't look unintended to me, but only Khaled can confirm/deny.

I haven't yet seen a network that uses "&" in both $prefix and $chantypes. IMO, mIRC should hotlink according to raw 5 at any rate, however "niche" the chars used.

Every network has & in chantypes, as it's part of the IRC protocol, so any network with the owner mode +q should have both. Lots of networks have owner mode, since it's part of UnrealIRCd.

Similarly, and as I alluded to before, other networks have even MORE user modes which can cause problems:



If mIRC hotlinked according to 005 on the above network, +foo would hotlink a channel.

There are also networks like IRCNet which are even more problematic:



Where !foo would hotlink a channel. Confusing much?

This is wrong. Some networks have it disabled.



Charybdis IRCd config. This also applies to freenode's fork of charybdis that gave the RAW 005

You're right. I noticed that some networks do have it disabled, but there is still a high possibility of overlap. My example of an overlap in "+" is even more problematic, since a + user mode prefix is much more common than & anyway, and that scenario exists.

But in any case, hotlinking within the same network isn't even the only potentially confusing issue. More confusing is the fact that mIRC would have different hotlinking semantics across networks for features that most users are not aware of. A user on rizon and efnet would see &text hotlinked as a channel on one network and as a nickname on another. I think this would confuse users who don't know about & as a chantype, as well as those who are on many channels on both networks and don't necessarily consider the network of a channel they are currently looking at. Going back to our real example, +text would do the same thing across networks. I don't think *any* user would expect +text to hotlink as a channel. I think the UI should follow the element of least surprise here, and frankly, there are some prefixes that I don't think should ever be hotlinked as a channel for that reason. +text is certainly one of them. I'd argue that &text is probably uncommon enough to be opt-in via script as well, especially since, as you pointed out, it's disabled on at least a few large networks (rizon seems to disable it as well).

I still hold that precisely because of that mIRC should not cause further confusion by hotlinking on some valid channel chars but not on others. Do it consistently or not at all.
Of course there's a potential for confusion in abovementioned server setup. I agree that it's suboptimal. But the issue is of server-side origin and hence should be addressed by the server, not by the client. Also, the chance of the server being configured like that deliberately is considerable, in that case mIRC should not patronize its users.

Thanks this issue has been fixed for the next version. As with previous versions, the next version will hotlink on channel prefixes listed in the numeric 005 CHANTYPES token.