girzel / ebdb

An EIEIO port of BBDB, Emacs' contact-management package
67 stars 12 forks source link

Affixes for structured names should be displayed #112

Closed cpence closed 10 months ago

cpence commented 10 months ago

If the user provides an "affix" in a structured name component, this should be displayed, just before the last name part of the name. (i.e., if "van der" is added as an affix to the last name "Meer" and first name "Peter", the contact (as well as the structured name field) should display as "Peter van der Meer"). I don't think that EBDB does any sorting right now, but if it did, it should ignore affixes when sorting (at least in most countries that actually use affixes; I know this is true for Dutch and Spanish affixes).

Thanks for a great package!

girzel commented 10 months ago

Thanks for the report! To be perfectly honest, I copied the "affix" slot over from BBDB, back when EBDB was starting out as patches to BBDB, and I've never really understood what it was for. My understanding is that "affix" is a general term, of which "prefix" and "suffix" are specific types. So what's just a plain "affix"? Shouldn't something like "van der" just be a prefix?

I'm happy to fix whatever needs fixing here, so long as I understand what's actually supposed to be happening!

cpence commented 10 months ago

Hmm, on reading further this is a very fair point! In other code -- e.g., in BibTeX name parsing -- it looks like there are only prefix and suffix parts (i.e. prefix = anything lowercase at the start of last name, suffix = III, Jr., etc.) and there's no such thing as an "affix."

vCard doesn't specify anything about those parts of name structure.

So there's actually a pretty hard decision to make here. I should almost certainly have been using "prefix" for Dutch names, so in that sense this is a mistaken report! Perhaps "affix" should be removed so that "prefix" and "suffix" can be standardized?


But, this actually leads to another bug:

I'm using ebdb-read-name-articulate to enter name parts separately. Say I create a contact with the surname "van der Meer" and the first name "Peter". Then I hit E on the contact name to bring up the structured edit buffer, and I move the "van der" from the surname into the (newly created) prefix field, and I hit apply and accept.

That doesn't change the original contact name, creating instead a new "alt name" field, in which the prefix field is printed twice: "Peter van der van der Meer." That seems like a proper bug in any case?

girzel commented 10 months ago

That is a bug, and one that I've noticed and been too lazy to fix. The customize setup can't currently distinguish between when it's editing the contact's principle name, and when it is editing a alternative name, and defaults to assuming the latter. I have been meaning to fix that for months, and will try to get to it today. The doubled prefix new to me, but presumably I can clear it all up at once.

Regarding affix, I just went back and looked at BBDB's code as it stands now, and all it has is "affix", no prefix or suffix. There's still bbdb-lastname-prefix, but that is only used in constructing the last-name regular expression. So maybe in the meantime BBDB, too, has opted to simplify things. It's not too hard to "upgrade" people's databases by converting any "affix" to a "prefix" (under the assumption that's what people were mostly using it for), though I don't know how disruptive that might be.

Regardless, thanks for the report.

girzel commented 10 months ago

Both of these issues should be fixed in the next release (0.8.18), please re-open if you're still seeing weirdness, thanks.

cpence commented 10 months ago

Fantastic, thanks so much, and thanks for all your work on EBDB! It's really becoming a world-class contact manager.