[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Orgmode] Re: Advice sought on managing decision alternatives.

From: Carsten Dominik
Subject: [Orgmode] Re: Advice sought on managing decision alternatives.
Date: Sat, 7 Feb 2009 01:18:52 +0100

Hi Tom,

On Feb 6, 2009, at 9:07 PM, Tom Breton (Tehom) wrote:

Hi Tom,

WIth you patch, we have right now

CHOOSE    as the prefix
choseness as the interpretation
org-decision as the name of the module.

My request would be to maybe use `choose' also as the
interpretation symbol, or, alternatively, CHOSENESS
as the prefix.

Yes.  I think "choose" is best; the ambiguity between "chosenness" and
"choseness" just invited difficulties.

Always feel free to suggest alternatives to my naming.  Sometimes my
initial ideas go in a funny direction. Eg, my initial thinking, which I
now abandon, was:

* org-DECISIONS.el because it supports decisions.
* CHOSENNESS because it's the property the item has of being chosen or not.
  As William observed, it's grammatically correct but rare.
* CHOOSE because I saw that CHOSENNESS has problems.

So "choose" it is. I'd like to rename the file org-choose.el as well, now
that I think about the naming.


Do you want a patch for it?

Yes, against current org.el, please, if you do not mind,
because I have not yet applied your earlier patch.

For customizing org-todo-keywords, instead of explicitly
offering `choseness', maybe we can use a symbol field
where people can type into.

It's more flexible but offers less support to the user. Maybe we can have the best of both worlds by restricting the choice to interpretations that
available modules support.  Ie, something like this:

* Object: a variable that holds the names of the interpretation symbols,
or of the ones that aren't built in.
* Behavior: interested modules add their interpretation symbol to the list
* Behavior: When customizing org-todo-keywords, offer the symbols from
  that list as choices for interpretation symbols.

This sounds perfect.

The primary difficulty would be getting widgets to understand that.

Yes.  Right now, I do not know how to do this, therefore
my more primitive proposal. Yours is better, if you can
make the widget work...

- Carsten

That would turn your patch into a generally useful system
of hooks where other ideas could be implemented as well.

What do you think?

Sounds good to me.

Tom Breton (Tehom)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]