[Orgmode] Re: Advice sought on managing decision alternatives.
Hi Tom, I have now added org-choose.el, it is part of the current git status. A few comments: On Feb 7, 2009, at 9:46 PM, Tom Breton (Tehom) wrote: Hi, Carsten. Here is the new patch to org.el and the new org-choose.el A couple of notes: * As we talked about, decisions and chosenness are now called choose everywhere. Great. * I was able to add the library-aware customization we talked about. This is nice, I earned something new! :convert-widget. * I also added new variable `org-todo-normal-interpretations' - see explanation below. See my comments below * New test file. Essentially the same, with name replacement. I have not run the tests myself yet. * Didn't append the example files; they are all unchanged from before. *** About `org-todo-normal-interpretations' You said your idea was to make a generally useful system. I noticed that one thing was still hard-coded. It's the part of org-todo that finds the next entry: (memq interpret '(sequence choose)) ... (memq interpret '(type priority)) Yes, this is correct. I appreciate you noticing this additional point where changes have to be made. However, for now I have opted for a different solution: I made the sequence interpretation the last test in the cond chain, so that all interpretations that are not `type' will fall back to this mechanism. I envision that we can add another hook if someone wants an additional way of handling this. I would like to minimize the number of variables where an add-on has to insert itself. I have commented the corresponding line which tries to add to the non-existing variable org-todo-normal-interpretations' in org-choose.el I hope you agree with this solution, if not let me know. I think what is missing now is documentation. It seems to me that there should be some minimal documentation in org-choose.el, and it would be great to get a tutorial on Worg which describes this in more detail. Thanks a lot for this contribution, and for your precision and attention to detail. - Carsten ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Advice sought on managing decision alternatives.
Hi Tom, On Feb 8, 2009, at 9:25 PM, Tom Breton (Tehom) wrote: I think what is missing now is documentation. It seems to me that there should be some minimal documentation in org-choose.el, and it would be great to get a tutorial on Worg which describes this in more detail. What sort of format are you looking for? Well, some ASCII documentation could be inserted into org-choose.el as a file commentary. If you use a standard header with keywords for the finder (M-x finder-commentary and friends), that would be useful. Tutorials on Worg are usually written in Org, but you can upload any format you like (or send it it me) and we wil publish it there. - Carsten ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Advice sought on managing decision alternatives.
Hi Tom, I am now looking at org-decision and start to integrate it. There is one point I'd like to discuss. My preferred way to do the integration is opening a new hacking door which will not require changes to org.el for other people doing similar stuff. So my idea would be to search for ^#\\+\\(\\([a-zA-Z]+\\)_\\)?TODO when scanning the buffer, i.e. that any keyword could precede TODO in such a line. I would then like to call the filter hook, using that keyword as interpretation. WIth you patch, we have right now CHOOSEas 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. For customizing org-todo-keywords, instead of explicitly offering `choseness', maybe we can use a symbol field where people can type into. That would turn your patch into a generally useful system of hooks where other ideas could be implemented as well. What do you think? - Carsten On Jan 31, 2009, at 5:21 AM, Tom Breton (Tehom) wrote: Here is org-decisions. All 68 tests ran successfully. I hope it is satisfactory. If it's not, please let me know. Please find attached: * org-decisions.el * diffs to org.el * test-org-decisions.el. * 6 example files in testing A few notes: ** Test files I included 6 example files that I used in testing, and my test file test-org-decisions.el. test-org-decisions.el uses my tester rtest, which is unfortunately in flux at the moment. Still, I felt it would be best to make it publicly available. ** Use of cl I used cl in org-decisions.el. I hope that's not a problem, but if it is I can rewrite the parts that use cl. * pushnew * position * destructuring-bind * defstruct ** Use of allout org-decisions.el and test-org-decisions.el use allout for structuring. I removed the mode: allout line so that they can be read without allout present. Tom Breton (Tehom) org-decisions.elorg.el.difftest-org- decisions.elsimple.orgw-1-chosen.orgw-2- types.orgnonautomatic.orgno-sibs.orgw-some-nils.org ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Advice sought on managing decision alternatives.
On Fri, Feb 6, 2009 at 7:08 AM, Carsten Dominik domi...@science.uva.nl wrote: CHOOSEas 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. I believe the standard spelling is chosenness, although it is a very rare word in English outside of Judaism :) Cheers Will -- Dr William Henney, Centro de Radioastronomía y Astrofísica, Universidad Nacional Autónoma de México, Campus Morelia ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Advice sought on managing decision alternatives.
Hi Tom, [...] WIth you patch, we have right now CHOOSEas 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? 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. The primary difficulty would be getting widgets to understand that. 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) ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Advice sought on managing decision alternatives.
Hi Tom, On 2009-01-31 13:36:20(-0500), Tom Breton (Tehom) wrote: Also, I am interested in the testing environment, and what you made here may end up to be enough to establish a testing framework for Org-mode. If it turns out to be like this, maybe you can make a tutorial on test creation and put that up on Worg? I would be willing to put the code needed for the testing environment into the contrib directory. Certainly. One thing, once my testing package rtest is in a stable state, I plan to release it on its own, possibly as a sourceforge project. But I have no objection to you also putting in the org contrib directory. As part of the rewrite of org-remember I am working on I have been adding tests using ert (at the time I started it you suggested not to use rtest as it was undergoing a lot of changes[1]). I haven't run into any problems with ert so far, but I would be willing to switch to another testing package if it becomes the standard for org-mode. I'd like to take a look at rtest, but the only version of I can find on the web is at http://www.panix.com/~tehom/my-code/rtest-3-0.tar.gz, which appears to be from 2001. Is there a more recent version available? James [1] http://article.gmane.org/gmane.emacs.orgmode/8817 -- |-James TD Smith-email/ahktenz...@mohorovi.cc-| ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Advice sought on managing decision alternatives.
Hi Tom, this looks awesome. Right now I am stabilizing everything to make my final release for Emacs 23.1, so it may be a week or two before I get to integrate this. Understood. Also, I am interested in the testing environment, and what you made here may end up to be enough to establish a testing framework for Org-mode. If it turns out to be like this, maybe you can make a tutorial on test creation and put that up on Worg? I would be willing to put the code needed for the testing environment into the contrib directory. Certainly. One thing, once my testing package rtest is in a stable state, I plan to release it on its own, possibly as a sourceforge project. But I have no objection to you also putting in the org contrib directory. Tom Breton (Tehom) ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Advice sought on managing decision alternatives.
Hi Tom, this looks awesome. Right now I am stabilizing everything to make my final release for Emacs 23.1, so it may be a week or two before I get to integrate this. Also, I am interested in the testing environment, and what you made here may end up to be enough to establish a testing framework for Org-mode. If it turns out to be like this, maybe you can make a tutorial on test creation and put that up on Worg? I would be willing to put the code needed for the testing environment into the contrib directory. - Carsten On Jan 31, 2009, at 5:21 AM, Tom Breton (Tehom) wrote: Here is org-decisions. All 68 tests ran successfully. I hope it is satisfactory. If it's not, please let me know. Please find attached: * org-decisions.el * diffs to org.el * test-org-decisions.el. * 6 example files in testing A few notes: ** Test files I included 6 example files that I used in testing, and my test file test-org-decisions.el. test-org-decisions.el uses my tester rtest, which is unfortunately in flux at the moment. Still, I felt it would be best to make it publicly available. ** Use of cl I used cl in org-decisions.el. I hope that's not a problem, but if it is I can rewrite the parts that use cl. * pushnew * position * destructuring-bind * defstruct ** Use of allout org-decisions.el and test-org-decisions.el use allout for structuring. I removed the mode: allout line so that they can be read without allout present. Tom Breton (Tehom) org-decisions.elorg.el.difftest-org- decisions.elsimple.orgw-1-chosen.orgw-2- types.orgnonautomatic.orgno-sibs.orgw-some-nils.org ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Advice sought on managing decision alternatives.
Hi Tom,
I went through your draft and I think this is interesting functionality
which would be really nice to have.
I also see that you have thought carefully on how to implement it
and minimize impact on the core code, which I appreciate.
I would be happy to to make/accept the following changes
to org.el:
In addition to SEQ_TODO and TYP_TODO, I could look for similar
words. We could even do this in a general way, looking for
#+XYZFOOBAR_TODO:
and making this call a special function org-todo-setup-xyzfoobar, which
could then be defined in add-on packages.
As you want to re-use the internal functions Org uses
to change states, I would like to change this code as
little as possible, even going beyond what you already proposed:
My proposal would be:
Your add-on defines a setup function which is actually a *filter*
function.
It gets passed the list of words resulting from parsing the
#+CHOOSE_TODO: line, or equivalently such a list found in
org-todo-keywords.
For example:
#+CHOOSE_TODO: REJECTED - NOT_CHOSEN 0 MAYBE LEANING_TOWARDS + CHOSEN
or
#+CHOOSE_TODO: REJECTED(r){-} NOT_CHOSEN(n){0} MAYBE(m)
LEANING_TOWARDS(l){+} CHOSEN(c)
The format would be entirely up to you, as long as you do the following:
The filter function must return a list as it is *normally*
expected for TODO keywords, with flags for fast selection
and note taking, maybe a | entry to separate DONE entries
from the rest, but any other special stuff of your interface
removed, for example:
(choseness REJECTED(r) NOT_CHOSEN(n) MAYBE(m)
LEANING_TOWARDS(l) | CHOSEN(c))
Org will then process this return list appropriately, set up
keys for fast selection, arranges for notes and time stamps
to be recorded etc.
The interaction type does very little indeed inside Org, it
only decides if a cycling command should go to the next
step (sequence) or jump to the first DONE state (type).
I think we should treat any other interaction types like
sequence in this respect.
This would be all as far as Org is concerned. No need to
change any code at all.
I will then add hooks wherever you need them, they will
be called whenever a TODO keyword changes and your code
can react to it.
One important precaution would be to make sure that one does
not end up in infinite loops, so maybe when the hook is called,
bind it dynamically to a nil value while you mess around with
with the status of the siblings. Maybe do the same thing with
the variables that trigger time stamp and note recording.
What do you think?
- Carsten
P.S. What is you copyright status with the FSF?
On Jan 19, 2009, at 4:33 AM, Tom Breton (Tehom) wrote:
On my last two requests, Carsten had better ideas and my proposal
really benefitted from them. So I'm asking for advice on the design.
** Rationale
When I make a decision, in org-mode, I write down the set of
reasonable alternatives that I see, each one as an item. Then I make
notes about each one and then choose.
Often the process is messy. I sometimes:
* add a new alternative later
* realize an alternative is fatally flawed and permanently reject it.
* choose one but come to regret it. Then I need to unchoose it and
then choose another.
* Realize that what I thought was an alternative is really a distinct
yes/no choice.
* Add a related yes/no choice to the group - I could make a new
subtree for each new related choice, but usually once I find one
related choice, I soon find many, so that's a lot of restructuring
for little benefit.
** The overall idea:
So I want a way of keeping track of alternatives and their state of
decision. Where possible, I'd like this to automatically stay in a
sensible state. Eg, if one alternative is chosen, no other is.
** A detailed example
*** Item markings
For example, each item could be marked from this set of markings:
* CHOSEN
* Invariant :: The other items are marked NOT CHOSEN or lower
* Reaction :: If another item becomes CHOSEN, this item becomes NOT
CHOSEN
* Reaction :: If another item becomes LEANING TOWARDS, this item
becomes MAYBE.
* LEANING TOWARDS
* Invariant :: The other items are marked MAYBE or lower.
* Reaction :: If another item becomes LEANING TOWARDS, this item
becomes MAYBE.
* MAYBE
* The default marking. New items in the group get this marking
unless some item is marked CHOSEN, in which case new items get
NOT CHOSEN.
* Reaction :: If another item becomes CHOSEN, MAYBE becomes NOT
CHOSEN.
* NOT CHOSEN
* Reaction :: If it becomes the case that no item is CHOSEN, NOT
CHOSEN items become MAYBE.
* If marks are to be changed by moving up and down this scale, an
item could become NOT CHOSEN in the course of becoming
REJECTED. This requirement keeps me from adding an invariant
that if any item is NOT CHOSEN, exactly one item should be
CHOSEN.
* REJECTED
* Remains marked REJECTED regardless what happens to
[Orgmode] Re: Advice sought on managing decision alternatives.
P.S. What is you copyright status with the FSF? I believe I'm already good to go. A few years back when I contributed some code to emacs' lread.c, RMS had me sign and send the letter that legally enabled FSF to include it. IIUC, that step only has to be done once for any code contributor. Your add-on defines a setup function which is actually a *filter* function. OK, sounds good. And makes it a bit easier to test. The interaction type does very little indeed inside Org, it only decides if a cycling command should go to the next step (sequence) or jump to the first DONE state (type). I think we should treat any other interaction types like sequence in this respect. Here it would also distinguish chosenness from the other interpretations, but that would be entirely inside org-decisions.el. I will then add hooks wherever you need them, they will be called whenever a TODO keyword changes and your code can react to it. OK. One important precaution would be to make sure that one does not end up in infinite loops, so maybe when the hook is called, bind it dynamically to a nil value while you mess around with with the status of the siblings. Maybe do the same thing with the variables that trigger time stamp and note recording. Right. I had already planned to let the hooks to nil; I will do the same for the time stamp and note recording variables. Thanks for the advice. I will code it up and send it. Tom Breton (Tehom) ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
