lucc / khard

Console vcard client
https://khard.readthedocs.io/en/latest/
GNU General Public License v3.0
600 stars 65 forks source link

[Regression] Nickname occurs in the output of `khard email --parsable` #251

Closed protist closed 4 years ago

protist commented 4 years ago

As per the recommendations, I have the following in ~/.mutt/muttrc:

set query_command="khard email --parsable %s"
bind editor <Tab> complete-query

When I attempt to invoke khard in neomutt, the nickname also appears in the recipient field. For example given the following vcard:

Formatted name : Joe Citizen
First name : Joe
Last name  : Citizen
Nickname : horrible_human_being

Neomutt addresses the email to

"Joe Citizen (Nickname: horrible_human_being)" <jcitizen@foo.com>

This occurs with the current khard 0.16.1 (and 0.16.0), but this behaviour was not present in 0.15.1. I'm using python 3.8.2.

FWIW I notice other improvements in 0.16.0. Firstly, in both 0.15.1 and 0.16.0/0.16.1, I can search by nickname perfectly fine in general. However, the searching behaviour is slightly better in 0.16.0/0.16.1 if there are conflicting matches. Let's say I have two vcards:

  1. Michael Smith, with nickname Mike
  2. Mike Jones

With 0.16.0 or 0.16.1, searching for Mike will bring up both options in the selection dialogue.

However, with 0.15.1, it immediately auto-completes to Mike Jones, with no option to select Michael Smith.

lucc commented 4 years ago

I have added the branch test/251 but can not yet reproduce the nickname problem. I was suspecting you have show_nicknames=True in your config even though you did not say. But with or without this setting my tests fail to show your described behaviour: e430156

Please tell me what you are doing different from the tests.

Ok now I can reproduce your behaviour (f26650b). You seem to have show_nicknames=True in your config. Is that desired?

protist commented 4 years ago

Thank you for the tests. Sorry @lucc, I should have been more specific. Yes, I can confirm that I see this bug with show_nicknames = yes in ~/.config/khard/khard.conf.

Without this line, there is no bug. However, without this line, I can no longer search by nickname either. e.g. in the example above, searching for Mike autocompletes to option 2, with no ability to select option 1.

lucc commented 4 years ago

I think I can reproduce the missing search result with the email subcommand if show_nicknames=False and the contact would have a matching nickname: 3133b08

The reason for this change in behaviour is for one part due to the introduction of the khard.formatter.Formatter class which now handles the list output also for the email subcommand. On the other hand I have plans for the querying code and syntax in #131 which would change the matching behaviour again. I am unsure if and how exactly I can "fix" this issue.

The relevant code is https://github.com/scheibler/khard/blob/develop/khard/khard.py#L872-L885 and https://github.com/scheibler/khard/blob/develop/khard/formatter.py#L50-L59

I will think about it, suggestions welcome.

lucc commented 4 years ago

@protist I opend #253, if you have the time you can test your issue against that branch. I think I will implement a proper solution for your issue only on top of #253.

About the proper solution: I think the desired behaviour should be that

What do you think?

protist commented 4 years ago

Thanks @lucc. I agree with both parts of your proposal.

I installed the branch/patch but the behaviour doesn't seem to change for me. I tested within Neomutt again, and the nickname is still present in the To: field.

I'm not sure exactly how to use khard email --parsable <nickname> directly from the command line, but I'm happy to test it directly if it might remove other potential variables. The output looks like this at the moment:

$ khard email --parsable horrible
searching for '['horrible']' ...
jcitizen@foo.com    Joe Citizen (Nickname: horrible_human_being)    work
lucc commented 4 years ago

I merged #254 but the matching with and without nicknames is not included. That has to wait until after #253 because it is more complex and requires a decision.