Titus von der Malsburg <[email protected]> writes: > On 2025-10-13 Mon 00:02, Rudolf Adamkovič <[email protected]> wrote: >> Ihor Radchenko <[email protected]> writes: >> >>> We have a non-syntax convention that EMAIL: ... EMAIL+: ... >>> properties are concatenated (according to `org-property-separators') >> >> +1 Semantically, this is the standard way, supported directly by the Org >> APIs. It is what an Org user would expect to see used in the key-value >> context of Org properties. Put simply, KEY and KEY+ is the standard >> idiom, as seen everywhere in Org. BTW, I have been using this idiom for >> invoicing, now for many years, and it works great in user code as well.
> However, I’d still argue that there is an issue because > `org-entry-properties' returns an arbitrary and undocumented subset of > the properties when a property has multiple instances. Given the syntax > above, this case should not arise, but I think it still be more > consistent and correct to simply return everything. Assoc and friends > will ignore the duplicates, it should therefore not cause harm (as > explained in my last message). > > Plus, I think there is a documentation bug, since this particular use of > the PHONE+ syntax is not explained in the documentation. Let me know if > you want me to create a patch for that. Hmm. The :PROPERTYNAME+: syntax for adding to the value of PROPERTYNAME is documented in the manual. It is illustrated both for "#+PROPERTY:" keywords and for property drawers in the CD-collection example. https://orgmode.org/manual/Property-Syntax.html But I see some other nitpicks: The `org-property-separator' variable is not documented in the manual (at least not on that page, and not in the variable index). It probably ought to be mentioned on the Property Syntax page. That page goes on to say: "Note that a property can only have one entry per drawer." This clashes with the terminology used everywhere else on that page, where "entry" means an Org entry (headline and content). It could also be interpreted to conflict with Ihor's statement upthread that "syntax-wise, properties do not have to be unique", i.e. the same property can be entered several times in the same drawer (but only one such "entry" or instance will be retrieved). Here "entry" should perhaps read "value": "Note that a property can only have one value per drawer." If we make that change, perhaps that line should be moved up to immediately before "If you want to add to the value ...", otherwise it might be confusing. Regarding the feature: Personally, I'm happy with the current arrangement that does not seek to define a format for multiple-value properties, but allows for multiple values to be entered on separate lines with the `+' postfix and concatenated into one value with separators customizable per-property. This leaves the format and implementation to users/developers, who will need to explicitly split on the separator to create a list from the string value. As for the inconsistent behavior Ihor mentioned for duplicate instances of a property, note that `org-entry-properties' returns the first value listed only when called without arguments. But it can take the name of a target property as an optional argument, it returns the last value listed, like `org-entry-get' does. I think that weakens the part of Titus' argument that allowing duplicate instances to be a list of values would not break any setups because people would `alist-get' the first value anyway. (There is no reason a consistent behavior *has* to be defined for something one ought to avoid doing, and the choice of first or last value is arbitrary. But I think it would be preferable if `org-entry-properties' consistently did the same thing with or without arguments, and to me, at least, it makes intuitive sense that new lines with the same property would "overwrite" the value, so the last value should apply.) Regards, Christian
