Forums Feature Suggestions Add a note...

Would be nice to be able to add a personal note about a user on a per channel per server basis. mIRC could then store that and when I come back on another day, I could see a note I wrote about that person. Would be useful for little reminders.. such as a/s/l, or email, or what I thought about this person - stuff that could help me in my future interaction with them.

You mean like the Users tab in the Address Book? (ALT+B ...)

But you have only one addrbk.ini (one section per nick, for all networks and of course -chans)
However, I don't know how a network- or even channel-based system could be added to the existing address book tab. You'll end up with too many choices (i.e. the respective required checkboxes/dropdown lists) to add a note either globally/per network/per channel. I think it would require a separate dialogue (and new identifiers anyway)... or a scripted sollution.

I see no problem with the Users tab in address book. In the off chance that you interact with the same nickname on multiple networks but that nick happens to be two different people, you can easily just prefix your note with the network, ex.:



Alternatively if you need to fill in the website,name,etc. details you can suffix the prefix or nickname with the network as well ("EFNet:josh", "freenode:josh").

But frankly I don't think that's even common enough a scenario to occur let alone be a nuisance in the case that it does.

I agree that channel-specific abook notes may be of use to few users only, but I don't agree that different nicks on different networks denoting different users is an "off chance". The tabs "notify" and "control" already have a server/network option to account for that, and "highlight" with a network-option has been suggested as well.
And of course you can sub-divide your abook data with a custom system like prefixes. But this renders most of $abook().blah useless and breaks related scripts. Maybe I'm thinking too much about the scripting scope here...

I didn't say different nicks on different networks.. I said the interacting with the *same* nick on different networks where the two nicks are *separate people* is going to be highly unlikely.

Dealing with different nicknames on different networks is easy, Address Book already deals with this with just the nickname.

And no, it doesn't render $abook() useless because you just specify the nick with the network prefix:

//echo -a $abook($+($network,:,$nick)).note1

It won't "break" any existing scripts because no existing addrbook scripts have support for multiple networks to begin with (that I know of; if they do then this is moot anyway), so we're adding functionality here.

But again, you *only* need a prefix if you have the unlikely scenario where you have EFNet:NICK and freenode:NICK and NICK are two different people on EFNet and freenode *AND* you know them both well enough to store info about them. Otherwise there's generally no multi-network problem.

Whops, I meant "same nick on different nets".

Maybe my last post wasn't very clear. I don't second the idea of channel-based entries, but I second the idea of abook entries bound to a network (optional - the way you may bind control/ignore/notify to a network).
Of course you can write some script using custom prefixes to denote different networks (or channels). But I'd regard it as a workaround only - as you won't have any inter-script compatibility (i.e other scripts around $abook(nick).something, I therefore called it "useless"). In addition, the user has to follow one "custom" syntax for all his abook modifications. That's not intuitive like a dialog item to select/enter a network.
On the other hand side, a new dialog item (drop/edit) to enter a network, and the respective ().network property (like in $notify(), $protect(), $ignore() etc) would allow inter-script compatibility and simply would expand the existing tab and existing identifier.
About the question what $abook(<nick>)[.xxx] should return for multiple entries (different networks) for some nickname, it could behave like $aop(<mask>) etc, that is: return a match only if the entry is set to no network or the current network.

I guess one reason for not having this dialog-item and identifier-property as yet is not because it wouldn't be of much use but rather the structure of the addrbk.ini:
Although this ini is not treated like other mIRC ini files (e.g.: control codes are preserved in your notes; the [] char of nicknames isn't converted to ~ in the section name) and an optional network=bla item would be possible, you'd end up with multiple "sections" of the same name. This may or may not be a problem for mIRC itself. In any case, all other mIRC ini files that handle "network-sensitive" entries (e.g. control.ini) have a different structure - and changing the current structure is no option as it would break compatibility with old versions.

The issue still comes down to the extreme unlikelihood of needing to separate content by network. Again, to people on an individual level, a nickname is unique across networks. It's unlikely that you know a "joe55" on EFNet and also know a "joe55" on DALNet but these joe55's are two different people. mIRC *could* cater to this off-chance situation, but I doubt it's worth it when you have pretty decent workarounds.