On 2025-10-13 Mon 13:16, Christian Moe <[email protected]> wrote:
> 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.
I noticed another inconsistency: If I request a particular property,
`org-property-separators' is obeyed, but it’s ignored when I request all
properties.
#+BEGIN_EXAMPLE
* Test
:PROPERTIES:
:N: Test
:PHONE: +12345
:PHONE+: +23456
:END:
(let ((org-property-separators '(("PHONE" . "X"))))
(org-entry-properties 1 "PHONE"))
(let ((org-property-separators '(("PHONE" . "X"))))
(org-entry-properties 1))
#+END_EXAMPLE
The first results in:
(("PHONE" . "+12345X+23456"))
But the second in:
(("CATEGORY" . "test") ("PHONE" . "+12345 +23456") ("N" . "Test")
("BLOCKED" . "") ("FILE" . "/tmp/test.org") ("PRIORITY" . "B") ("ITEM"
. "Test"))
Am I missing something? If not, I’ll have to conclude that
`org-entry-properties' cannot be generally used for multiple-valued
properties.
Titus
>
> (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
--
Titus von der Malsburg, Jun.-Prof. Dr.
Psycholinguistics and Cognitive Modeling
Institute of Linguistics, University of Stuttgart
https://tmalsburg.github.io
