From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bastien Subject: Re: Categories Date: Mon, 15 Oct 2007 12:32:00 +0100 Message-ID: <87abqkd367.fsf@bzg.ath.cx> References: <1sodf4n1wn.fsf@home.net> <87przk8nom.fsf@bzg.ath.cx> <877ils8jpu.fsf@bzg.ath.cx> <467cec015b737d0c4c69382db9d7f314@science.uva.nl> <87fy0gw9my.fsf@bzg.ath.cx> <87bqb4uri3.fsf@bzg.ath.cx> <87r6k0tboe.fsf@bzg.ath.cx> <0sprzk9pcu.fsf@home.net> <87641cdniz.fsf@bzg.ath.cx> <87tzovjeer.fsf@bzg.ath.cx> <13k5prcg2a.fsf@home.net> <87bqb3jcsm.fsf@bzg.ath.cx> <77zlykith7.fsf@home.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IhNEw-0001DQ-Op for emacs-orgmode@gnu.org; Mon, 15 Oct 2007 06:32:02 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IhNEw-0001DA-7V for emacs-orgmode@gnu.org; Mon, 15 Oct 2007 06:32:02 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IhNEw-0001D7-4F for emacs-orgmode@gnu.org; Mon, 15 Oct 2007 06:32:02 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IhNEv-0006Dp-JK for emacs-orgmode@gnu.org; Mon, 15 Oct 2007 06:32:01 -0400 Received: by ug-out-1314.google.com with SMTP id a2so182562ugf for ; Mon, 15 Oct 2007 03:32:00 -0700 (PDT) In-Reply-To: <77zlykith7.fsf@home.net> (Richard G. Riley's message of "Mon, 15 Oct 2007 12:04:52 +0200") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Richard G Riley 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