While we have a good handle on plusplus when someone is trying to plusplus a slack entity itself, we currently don't do anything when the attempt is on a subscore that begins with a slack entity.
e.g. @zdaemon.whap++ should give us zdaemon.whap: 1
Instead, we get something like @u06k3pt1rar.whap: 1
Ideally, this would be detectable and handled in a similar way to the raw slack id.
Embedded slack ids are also be a problem (e.g. foo.@zdaemon.whap++), but they take a bit more work to actually create. They don't auto link if you type them naturally, only if you add the prefix after you have the linked identifier. It is likely that handling these is also the correct thing to do (if only because of the work required to actually create them implies clear intent on the part of the user).
Email addresses that have been converted to slack links could have a similar issue, but it probably can be ignored since it can be hard to tell where the email address begins and the embedding ends without the embedding, and slack goes out of its way to prevent you from manually curating these [especially for prefixes, where every attempt I've made has merged into the linkified address rather than getting embedded markdown]. Suffixes appear to be able to be created, but are still confusing when flattened anyway. (As an example for why slack finds this challenging, consider sub identifiers: is foo@bar.com.whap a subidentifier, or just a larger email address for a different tld?). So, I think we can ignore email addresses for now if only because its a rare use case to begin with.
While we have a good handle on plusplus when someone is trying to plusplus a slack entity itself, we currently don't do anything when the attempt is on a subscore that begins with a slack entity.
e.g. @zdaemon.whap++ should give us zdaemon.whap: 1
Instead, we get something like @u06k3pt1rar.whap: 1
Ideally, this would be detectable and handled in a similar way to the raw slack id.
Embedded slack ids are also be a problem (e.g. foo.@zdaemon.whap++), but they take a bit more work to actually create. They don't auto link if you type them naturally, only if you add the prefix after you have the linked identifier. It is likely that handling these is also the correct thing to do (if only because of the work required to actually create them implies clear intent on the part of the user).
Email addresses that have been converted to slack links could have a similar issue, but it probably can be ignored since it can be hard to tell where the email address begins and the embedding ends without the embedding, and slack goes out of its way to prevent you from manually curating these [especially for prefixes, where every attempt I've made has merged into the linkified address rather than getting embedded markdown]. Suffixes appear to be able to be created, but are still confusing when flattened anyway. (As an example for why slack finds this challenging, consider sub identifiers: is foo@bar.com.whap a subidentifier, or just a larger email address for a different tld?). So, I think we can ignore email addresses for now if only because its a rare use case to begin with.