Re: [O] org-depend: TRIGGER XYZ(KEYWORD) not working

[Karl Voit]

Hi Adrian,

Glad that you replied - I was worrying that this thread is going to
die before any improvement can be developed ...

* Adrian Bradd <address@hidden> wrote:
>
> First observation:
>>
>> When I set the heading 1 to DONE (without assigning it any other
>> keyword), the TRIGGER events are ignored totally.  I guess this is
>> an edge-case that may be considered as a bug.
>>
>
> This is the result of Line 219 in org-depend.el:
>
> (unless (and (member from org-not-done-keywords)
>             (member to org-done-keywords))
>
> In this instance 'from' is set to nil so the 'and' returns nil and
> org-depend doesn't process the change of TODO to look for dependents. I
> don't know why it was defined this way as org-todo.el accepts headings with
> no TODO entry. I can't think of any reason other than explicitly blocking a
> user from processing a heading without a TODO entry, but it seems that if
> the user went to the effort of populating a TRIGGER property that they
> probably want this to be acted upon by org-depend.el.

I totally agree: there should not be any reason to accept missing
TODO keywords in this case as well.

> If there are no concerns raised in this thread I'll push a patch to all
> have org-depend process the example you listed.

Cool ;-)

>> Second observation:
>>
>> However, what is bugging me even more is that even when "heading 1"
>> has a TODO keyword assigned, in *some* cases, the TRIGGER event does
>> not get executed when I do it in my large Org-mode file.
>>
>> Copying the corresponding headings (the one with the TRIGGER prop
>> and the headings containing the "target" IDs) from my real-world
>> Org-mode file to my small test.org from above and marking the
>> heading that contains the TRIGGER properties to DONE, it then works
>> as expected.
>>
>> I then took the simple example from above, added a TODO keyword to
>> the heading 1, copied it to my real-world Org-mode file and even
>> this did not work: Heading 2 and 3 don't get their "NEXT" keyword
>> assigned.
>>
>> So the behavior changes within different Org-file contexts.
>> Therefore, I do have an issue creating a minimal example to
>> demonstrate the bug.
>>
>> Can somebody give me an advice how to debug this behavior?
>
> My only thought is that there is an ID clashing with your sample I=
> D and it
> is being updated instead of the heading you are interested in.
> org-depend.el looks at the local file for an ID and then looks globally for
> an ID match.

Well, the IDs I was using were unique over all of my files.
Valid guess but not the case at my setup.

> You could instrument 'org-depend-trigger-todo' to trace the behaviour while
> processing the TODO update.

I found out that following part does not return any TRIGGER line:

: ;; OK, we just switched from a TODO state to a DONE state
: ;; Lets see if this entry has a TRIGGER property.
: ;; If yes, split it up on whitespace.
: (setq trigger (org-entry-get pos "TRIGGER")    ;; <-- no result here!
:   triggers (and trigger (split-string trigger)))

So the whole procedure of looking for the IDs to trigger is not
reached at all. 

After that I edebug-defun org-entry-get and the difference between
working and non-working TRIGGER (non-nil list of property values
versus nil) can be found at:

: (let* ((local (org--property-local-values property literal-nil))

... within org.el (git maint 946f76d70)

Another edebug-defun of org--property-local-values shows that this
code does not return the list of values in the big file where it is
working with my working minimal file:

: (let ((v (and (re-search-forward
:            (org-re-property property nil t) end t)
:           (match-string-no-properties 3))))

I could not jump into re-search-forward (built-in function) but I
found out something fishy: The value for "end" held a position which
is *not* the correct one.

Instead of holding the end position of the property drawer of the
heading I invoked org-todo on, it held the end of the properties
drawer of the next higher heading which has a progress indicator in
it.

Examples:

     * Top-Heading
     
     ** TODO Here I invoke org-todo to DONE
     :PROPERTIES:
     :TRIGGER: 2017-12-03-target(TODO)
     :END:
     
     ** This should be changed to TODO
     :PROPERTIES:
     :ID: 2017-12-03-target
     :END:

... this is working (i.e., "This should be changed to TODO" gets its
TODO keyword).

     * Top-Heading with process indicator [0/2]
     
     ** TODO Here I invoke org-todo to DONE
     :PROPERTIES:
     :TRIGGER: 2017-12-03-target(TODO)
     :END:
     
     ** This should be changed to TODO
     :PROPERTIES:
     :ID: 2017-12-03-target
     :END:

... this is *not* working.

However, anticipating the wrong position:

     * Top-Heading with process indicator [0/2]
     :PROPERTIES:
     :TRIGGER: 2017-12-03-target(TODO)
     :END:
     
     ** TODO Here I invoke org-todo to DONE
     :PROPERTIES:
     :TRIGGER: 2017-12-03-target(TODO)
     :END:
     
     ** This should be changed to TODO
     :PROPERTIES:
     :ID: 2017-12-03-target
     :END:

... is working. And according to this:

     * Top-Heading with process indicator [0/2]
     :PROPERTIES:
     :TRIGGER: 2017-12-03-target(TODO)
     :END:
     
     ** TODO Here I invoke org-todo to DONE
     
     ** This should be changed to TODO
     :PROPERTIES:
     :ID: 2017-12-03-target
     :END:

... this is also working. So the update of the process indicator
causes the wrong property drawer to be parsed for the relevant
TRIGGER property. 

Contrary to my previous assumption, this is issue is *not* related
to big and small files. This is purely related to the existing or
missing process indicator of the upper-level heading.

I guess I have found the origin of the bug.

Can you please do me the favor and fix it for me. I feel
extraordinary proud of me having dig into elisp (which I don't know
how to code mostly) and found the bug ;-)

However, I can't fix it on my own :-(

> I have read your post on org-depend and found it insightful so thanks for
> that. 

You're welcome.

> When I was looking around at patching some new functionality into
> org-depend I was put onto org-edna[1] which was built as an alternative to
> org-depend. The syntax isn't compatible with org-depend, but org-edna is
> more powerful than org-depend. I am now using org-edna and am quite happy
> with it.
>
> [1] https://elpa.gnu.org/packages/org-edna.html

WOT!

Why did nobody tell me about org-edna yet? ;-)

Some of my proposed org-depend-improvements[2] found its way to
org-edna, as it seems. However, I do have to invest quite some time
to migrate to org-edna. Meanwhile, I'd love to see org-depend
working (again).

Thanks for the pointer to org-edna - this is going to be great I
think.

[2] http://karl-voit.at/2016/12/18/org-depend/

-- 
get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode:
       > get Memacs from https://github.com/novoid/Memacs <
Personal Information Management > http://Karl-Voit.at/tags/pim/
Emacs-related > http://Karl-Voit.at/tags/emacs/