Re: Categories

[Bastien <bzg@altern.org>]

Richard G Riley <rileyrgdev@googlemail.com> writes:

>>> There is no "properties_alL" which determine which properties you can
>>> add.
>>
>> Not relevant here, because there is no reason why the user would like to
>> limit the set of available properties.
>
> Must disagree. Completion doesn't *limit* the choices. It only
> provides existing properties as a choice. You are still free to create
> a new one.

My first point here is that completion over existing properties in the
buffer is enough, no need for a meta-meta-property like PROPERTIES_ALL.

My other point is: when doing `C-c C-x p' to select/edit the value of a
property, it's useful to limit the set of available values -- only when
this set is defined in the corresponding PROPERTY_ALL.

_ALL means "no other value is allowed".  Then if you want the completion
to offer other values when there is such a *_ALL property, you will have
to add this other values to the property first.

(I guess the confusion comes from the fact that we started speaking
about completion for the CATEGORY property.  The CATEGORY property is
historically bound to the entire buffer, so you might expect completion
to be performed on all the values that you have in this buffer.  But if
someone is pervert enough to have a CATEGORY_ALL in a subtree, then the
completion should not offer values that are *not* in this limited set.
CATEGORY is now a property like any other, and it should behave like 
any other... how sad it might be.)

> I understand that. I was referring to the condition where there is no
> "ALL" value. Then it should be (and another email suggests that is how
> Carsten implemented it) a pick from all existing properties 

Agreed.  And this is the current behavior :)

Best,

NB: maybe you'd be interested in the suggestion I make here about having
a "_MULTI" suffix: 

  http://www.cognition.ens.fr/~guerry/org-features-suggestions.html#sec-3

-- 
Bastien