add profile token

Do not put hash signs into file names, it makes the files inaccessible.

It would help if you explained what the problem is and how your proposed solution works.

The patch is not accessible with the # in the filename. Please post a renamed patch.

try accessing that patch with # urlencoded.. : http://drupal.org/files/issues/mail_edit.module-add-token-profile-%23652...

Right, that works, sort of...

Here are some preliminary comments:

1. If Token module is not installed, we get
   

   Fatal error: Call to undefined function token_get_list() in drupal-6\sites\all\modules\mail_edit\mail_edit.module on line 83

   There must be no hard-coded dependency on Token!

2. There's a newly introduced variable called $user_tokens that is initialized but not used anywhere.
3. Empty lines must be truly empty, no spaces!
4. The table looks neater than the definition list, which is a plus. However, we shouldn't go from one pre-rendered format (the definition list) to another pre-rendered one (the themed table). This should be a form_alterable hierarchical form element with a #theme function.
5. The user tokens are not universally applicable. The Subscriptions module is a big client of Mail Editor, and it uses the templates during cron, where there's no $user. I'm not sure how to best solve this problem, but presenting tokens that cannot be used is not good. Splitting
   $form['mail']['token_help']['help'] into
   $form['mail']['token_help']['help']['standard'] and
   $form['mail']['token_help']['help']['token_user'] would allow client modules to remove the latter.
6. I'm not sure we can make such a change within 1.x. I think we'd have to go to 2.x, because it may break client modules.

Some more thoughts:

7. Some of the tokens (probably) result in the same values, like !mailto and [mail], !username and [user], etc. on admin/build/mail-edit/user_register_admin_created/en. I'm a bit concerned that this might cause undesired confusion and support requests...
8. Maybe we ought to leave it up to the client module to decide whether it wants to enable the user tokens of the Token module? In fact, depending on the context of the mail, other Token categories might be applicable, too.

Actually, it IS the client module's responsibility to provide all the variables that are useful in its context. Maybe this should be an issue against the client module that isn't providing all you need, rather than attempting to throw in tokens that may not apply?

Any news for this feature??

No, sorry, no one cared enough to work on this for years, so it will never happen.

The D7 version has full support for tokens and then some.