Open gfarrell opened 3 years ago
Did you try to use the query syntax?
From the docs:
--
The query language allows the user to search for contacts where a specific term
matches in a specific field of the contact. When searching for foo
there
might be two contacts that match, because one is called "Foo" and the other has
an email address containing "foo":
$ khard list foo Index Name Email 1 Bar bar@foo-company.com 2 Foo boss@example.com
But when searching for name:foo
or emails:foo
one would only find one
of these each time because "foo" only matches in these specific fields of the
contact.
The available fields are the same as in the YAML format for contacts (an empty
YAML template can be seen with khard template
). Case does not matter, all
filed names will be converted to lower case. For field names with spaces (like
"Formatted name") the spaces have to be replaced with underscores (like in
formatted_name
). And the five name related fields "Prefix", "First name",
"Additional", "Last name" and "Suffix" are not available, but a simple
name:
query is possible which will search in any name field (including
nicknames and formatted names).
--
If your house isn't mentioned in the name field, something like khard show name:france
should work.
I'm aware, that's not the perfect solution for your issue but maybe it's a suitable workaround for now?
Alternatively why don't you search for "frances" directly? Or maybe you could support the interactive part of khard in your script like khard itself tries to do in the add-email subcommand used by email clients like mutt?
I'm thinking aloud - just ignore, if you've ruled that out already.
@scheibler
Did you try to use the query syntax?
The OP literally contains the exact query using the query syntax:
- add an exact-match mode to the search query where the string name:France can only match the full name /^France$/;
The way I understood it, the Friend has 'Frances' as the name and the house has 'France' as the name. So the query syntax (as-is) won't help.
@gfarrell even suggested changes to the query syntax that would solve the give use case:
- complicate (1) by adding regex syntax, supporting queries like the following: name:/^France$/;
Hi @scheibler and @mschilli87 :
As per my original message, @mschilli87 is correct: searching for name:France
brings up both the house in France and the friend Frances. In this instance name:France
doesn't help.
@gfarrell can you provide two (reduced and anonymized) vcards so that we can reproduce that? We could start by writing a test for the problem that name:...
seems to search in names and addresses. Because it looks to me as if we have two things here:
name:France
matches an address1. bug report: `name:France` matches an address
My understanding is that the contact with the French house has the name "France" so that would a naming issue, not a bug. (It's a perfectly valid name, but I think that's caused some confusion in this thread)
@lucc: as per my original post:
The problem with this is that sometimes there are two contacts with names which cause a collision (e.g. my house in France is called "France", and I have a friend with the last name "Frances").
This is not a bug report, as @d7415 has pointed out. It’s also the second time this issue has been misinterpreted but I’m not sure what else I can do to make the text clearer.
feature request: make khard more script able, by some means
As I wrote originally, I am happy to implement this improvement and have suggested how it might be done, but am simply waiting for some pointers from those more familiar with the khard code base as to what the best way in would be.
Well I did not expect a house to have a vcard with a name on its own. Nevermind.
In #189 I have proposed a --no-confirm
or --assume-yes
option. I think all relevant code that is affected by such options is in the khard.helpers.interactive
module. These two suggestions are related to the confirm
function. Here we are concerned with the select
function. For this a --last
or --select-none
option might also make sense
I would like to find a small set of options that covers as many cases as possible in order to keep the interface "uniform". So more suggestions for good options and discussion is very welcome before we start coding. I imagine the option to be toplevel for khard
not only for khard show
. We could also add this as a config option.
For the actual implementation we have to look at khard.helpers.interactive
to implement two versions of these functions or add optional arguments.
For the command line options we have khard.cli
. For the config parsing we have khard.condig
and the specification file khard/data/config.spec.
To really answer your question: I would be happy with PRs for a more scriptable interface. There is also a whole project about this: https://github.com/scheibler/khard/projects/1
I have not thought about how to implement it exactly so you can ask for more specific pointers if you have questions. I am also happy to help discussing the design first.
I wrote a script for khard so I can use it easily with Rofi (mimicking the functionality I used to have in Alfred when I was on macOS). The problem with this is that sometimes there are two contacts with names which cause a collision (e.g. my house in France is called "France", and I have a friend with the last name "Frances"). This causes my script to hang as khard wants interactive input. I've tried adding the UID into the list and then just selecting that with
awk
, but only a short UID is printed, so there are still multiple results when usingkhard show "uid:XXX"
.I can think of three ways of making khard more scriptable:
name:France
can only match the full name/^France$/
;name:/^France$/
;--first
flag which just picks the closest match (khard show --first "name:France"
).In fact, to make this completely scriptable, (3) is always necessary as two records might have the same names, but it's unlikely.
I'm happy to implement this and open a PR with (a) a bit of input on the best option; (b) a pointer as to where to start in the codebase.