Search within specific fields

[GSI]

How are search terms currently considered - and Is there a way to filter by certain properties of contacts?

Something like khard details category:2016 prefix:dr would return any doctors in the 2016 category.

[lucc]

Currently the search terms are used as a regex that is matched against the rendered vcard. But this proposal is very nice. It reminds me of https://github.com/notmuch/notmuch .

On the technical side: We have an option --search-in-source-files that searches for the regex in the source file (unrendered vcard) before parsing it (to save time). How should such a query be interpreted by this option?

[lucc]

@GSI I like your idea even more after I thought about it for some time. So here are my thoughts:

We are currently keeping the order of search terms (so for khard ls foo bar we search for foo.*bar but not bar.*foo) but that does not make sense for searching in fields because they don't have any inherent order. So in general one could relax the current implementation by using the python in operator on strings instead of regex searches and combine that with all(). This would effectively remove the order from search terms.

From there it might be easier to implement searching in specific fields. I imagine that search terms that do not start with a known field name are treated as before. This means that khard ls name:foo should look for "foo" in the name, khard ls foo should look for "foo" anywhere in the cards and khard ls foo:bar should look for "foo:bar" in any field.

One further question is how multible search terms for one field should be treated. So what does khard ls name:foo name:bar search for? For "foo" and "bar" in the name or for any of "foo" or "bar"? Or is it an error? We could also solve this question by introducing two new command line options --all and --any which could use the python functions of the same name to implement both of the above mentioned search strategies.

I am currently refactoring the basic class that represents a vcard in #169. I think that can help us to achieve the above points. You are welcome to have a look at it and leave your comments.

[GSI]

Quick comment due to time constraints:

Very reasonable thoughts! I'd "and" anything together. For "or" one may aways run two separate searches in sequence.

[vleonbonnet]

I created #237 to add a category search. This does not cover all fields, but covers my own workflow and might be of use to others as well until a full revamp of the search feature is completed.

[earboxer]

I think for this, it would be better to output the vcards as json objects, and have the users who want this level of filtering use the program jq.

khard ls --json | jq '. | map(select((.titles[0] == 'dr' or .first_name == 'doctor') and '2016' in .category)) or similar.

[lucc]

@earboxer that idea is also nice especially for general integration in scripts. The show command already has a --format option. This could be extended to also understand json. My first idea when I read you post was that we could reuse the code that produces the yaml version of a vcard. But sadly that is not yet refactored nicely. It still explicitly produces a lot of strings in yaml format directly and then joins them together. I was investigating a different path before (related to #146): Convert the vcard to a python dict and then turn that into a yaml with the help of a library. The problem here is that we do some custom formatting and add comments to the yaml output.

But if we had the conversion to that dict it might be trivial to output json with json.dump from the standard lib.

I still belive that a custom search syntax might be nice and should be added independently from the json output. The main reason being that it will work with all khard subcommands and not just show.

[lucc]

I noticed that we can already script ourself a --format=json equivalent because we can convert yaml to json:

khard show --format=yaml search term \
  | python -c 'import sys,json,ruamel.yaml;
               json.dump(ruamel.yaml.YAML(typ="base").load(sys.stdin), sys.stdout)'

[lucc]

I just merged a big branch into develop. You can search in specific fields with field:stuff. The fields are named like in the yaml output. Additionally there is the name: pseudo field that searches in all name related fields.

Missing: zsh completion and test by early users -> @GSI , @vleonbonnet I would be happy about feedback.

(@vleonbonnet sorry for not merging you suggestion before but this is what I was aiming at and I did not want to go forth and back with the feature and the syntax to first have one option and then these queries for every field.)

[lucc]

I will close this as it is implemented in 4fad9fd and the zsh completion is tracked in #270.

If no bugs arise I think I can release 0.17 around next weekend.

[GSI]

Time had me (or my machine) forget how to execute without installing.

Was it python khard.py? Which says:

Traceback (most recent call last):
  File "khard.py", line 17, in <module>
    from . import helpers
ImportError: attempted relative import with no known parent package

[lucc]

@GSI https://khard.readthedocs.io/en/latest/contributing.html#development

[GSI]

Okay at rev 4fad9fd using python -m khard details ... I can confirm these to work: name, categories, birthday

The rest fails to return a result for me: webpage, prefix, address, address.work.code, nickname, email, email.home

---

https://khard.readthedocs.io/en/latest/contributing.html#development

Minor typo there - says kard instead of khard for the module.

[d7415]

The rest fails to return a result for me: webpage, prefix, address, address.work.code, nickname, email, email.home

It looks like it's webpages rather than webpage and emails, not email. I haven't made addresses or nicknames work. prefix is specifically excluded:

the five name related fields "Prefix", "First name",
"Additional", "Last name" and "Suffix" are not available```

I haven't done a deep dive to check alternative names yet.

[lucc]

Currently the query syntax does not support nested field names like -F does. Maybe that was not clear from the documentation, will update.

I updated the docs: https://khard.readthedocs.io/en/latest/commandline.html#filtering-contacts

[lucc]

Release is finished:

• https://github.com/scheibler/khard/releases/tag/v0.17.0
• https://pypi.org/project/khard/0.17.0/