Psi

How about Thunderbird-like multiple address fields? Allowing only one address in each field would solve the problem with wrongly interpreted commas.
Moreover, this would be useful when we get Extended Stanza Addressing implemented in Psi.

<mawis>
I am using the Debian package 0.9.3-1 of Psi and just discovered that when I sent a message to a user, that has the nickname [RFL, 109.3fm] the message window opens and the recipient address is "[RFL, 109.3fm] <user@example.com>"

When I sent the message, Psi sends out to messages, one to [RFL and another to user@example.com.

I think the "," must be escaped before copying it to the message dialog, if this sign is used as a delimiter for specifying multiple recipient addresses.

With this bug, a user might generate nicknams, that cause Psi to send CCs of messages sent to this user to another address.

darcs patch over the mainline 5/6/2005

Done. Now The names are enclosed in double quotation marks (") as they are in the standard e-mail way. Double quotation marks in nicknames are turned into single quotation marks (') when displaying the names in the message dialog, so there are no conflicts.

Actually I think the "standard" email way is to quote the string and then replace
"
with
\"

I thought the users could think that's some kind of bug, and try to delete the '\'. So turning every " in the name into a ' makes any bad - I guess - and seems more clear to me - even thought the "standard" is escaping the "s...

So does this confusion happen in all email clients which already do this?

I don't think so. But in email clients is quite easy to realize when a piece of text which is suposed to be an e-mail address is so or not:

or whatever format an e-mail address has (I gess it is in the RFC).

In the code there's not such check. I thought of that, but would suppose big changes in the source - such as adding QRegExp - so I thought in that (temporal?) solution which was fast and needed no testing.

Very good evening.

Since this is a very annoying behaviour of Psi (even in 0.11), will this be fixed in near future? The severity of this bug already is high but unftly noone took care of it for more than 2 years. :-/

To add more information regarding the bug:

This also occurs on subscription requests. So if you have an incoming request from someone you already added to your roster (and used a comma in the name you assigned to the person), the outgoing subscription ACK will go to two JIDs, the name being split at the first comma :-/