Please add support for SORT-AS property

[sciurius]

To be able to properly sort (european) names it is necessary to be able to maintain the SORT-AS property of the name (N) field.

See https://datatracker.ietf.org/doc/html/rfc6350#page-21

[lucc]

Good idea @sciurius , pull requests for this would be welcome :)

I myself do not have the time to implement this for you, currently.

[sciurius]

I might give it a try. Do you have some clues where to start?

[lucc]

You probably want to look at the sort_contacts function in khard.py file first. There are also some other cases in khard.py where list of contacts are sorted but as far as I can see at a glance they might not be relevant for you (sorting by birthday etc., to be sure grep for "sort" in that file).

A single contact is represented by the classes in carddav_object.py, these are the kind of objects you are sorting.

The Config class and the command line parser (in config.py and cli.py) decide by which field in the vcard to sort.

I hope that help, you can always ask more (I have enough time to answer question or discuss designs, just not to do all the actual implementation).

[sciurius]

As a first step I've added "Sort as": to the template and code to fetch and store the SORT-AS parameter from/to the VCARD and yaml. This works, but if I modify only the SORT-AS, it is not detected as a modification and the entry is not updated. If I modify SORT-AS and anything else in the template the new SORT-AS value is correctly set and written to the VCARD.

Any idea where to look?

[lucc]

The code for that might be the yaml parsing function in the carddav class.

[lucc]

The parsing happens in YAMLEditable._parse_yaml but that is done by a library so the actual changes you would make are probably in YAMLEditable.update.

[sciurius]

Ah... To detect if the vcard has changed modify_subcommand uses ==, which is defined in CardDavObject to compare the pretty representation. Adding the sort-as param to the pretty print fixes this.

[sciurius]

Ok, it seems I've got it working. When sorting on last name I now use the SORT-AS if any.

This leads to a couple of questions:

1. Should SORT-AS always override, even when sorting on first name or full name?
2. Should we have a distinct sort mode to use the SORT-AS info (e.g. -s sort_as), which leads to
3. Should we then have a fallback specification (-s sort_as,last_name`)?

[lucc]

I think the RFC answers this question (exactly where you linked it):

1. yes
2. no, the SORT-AS i comma seperated and these fields correspond to the sorting value of the corresponding field in N (which is semicolon seperated)
3. no

I think you can copy the example from the RFC to a test case.