Re: [O] RFC: Extensible Dependencies 'N' Actions

[Adam Porter]

Hi Ian,

Don't have time to dig into this at the moment, but it sounds very
impressive and useful.  I look forward to giving it a try soon.  Keep up
the good work!

Re: [O] RFC: Extensible Dependencies 'N' Actions

[Ian Dunn]

Gergely Polonkai writes:

> • Some finders have missing documentation (although their names are pretty
> straightforward)

Yup, working on that.

> • Why the “new language”, why can’t it be lisp, or at least more lispish?

Initially, I made it similar to org-depend.el, but as parsing became
complicated, it has effectively morphed into lisp.  The keywords are all
symbols (they've got to be functions, after all), and the argument lists
are lisp lists.

I find this to be a good compromise between ease of coding for me, and
ease of understanding for the users.

> • You gave us a possibility to create naming clashes between targets,
> finders, etc. For example, I might want to file a note when a file of a
> project changes, so I use your file target, and create the file action. How
> will Edna know when to use which?

Right now, Edna will use the finder and ignore the action.  I didn't
want to force users to specify when to change from finders to actions or
conditions, so I just had Edna search for the functions.

Thinking about it, Guile uses the suffixes '!' to denote functions that
destructively change the input (like actions) and '?' to denote
predicates (like conditions).

If Edna looks for these characters at the end of the keyword (starting
character already means something), then that will allow users to name
both a finder and action 'file' (although the action would be 'file!').

And of course, thank you for your support and feedback.

-- 
Ian Dunn

Re: [O] RFC: Extensible Dependencies 'N' Actions

[Gergely Polonkai]

Hello Ian,

I just read the docs and I like it so far. There are three things I’d
mention:

• Some finders have missing documentation (although their names are pretty
straightforward)
• Why the “new language”, why can’t it be lisp, or at least more lispish?
• You gave us a possibility to create naming clashes between targets,
finders, etc. For example, I might want to file a note when a file of a
project changes, so I use your file target, and create the file action. How
will Edna know when to use which?

Hope I helped. I’ll give Edna a shot on Monday and probably get back with
some results.

Best,
Gergely

On Sat, Apr 22, 2017, 04:33 Ian Dunn  wrote:

>
> I've been working on something akin to org-depend.el called org-edna.
> Basically, Edna provides an extensible means of specifying blocking
> conditions and trigger actions.
>
> For example, Edna allows you to specify that a task should be blocked
> until all TODOs have been addressed in source code:
>
>
> Or schedule the following task for an hour after the current task is
> completed:
>
>
> The (semi-complete) documentation is here:
> http://www.nongnu.org/org-edna-el/
>
> I'd appreciate some feedback on it, whether the code or the
> documentation.
>
> --
> Ian Dunn
>

[O] RFC: Extensible Dependencies 'N' Actions

[Ian Dunn]

I've been working on something akin to org-depend.el called org-edna.
Basically, Edna provides an extensible means of specifying blocking
conditions and trigger actions.

For example, Edna allows you to specify that a task should be blocked
until all TODOs have been addressed in source code:

* TODO Address all TODOs in code
  :PROPERTIES:
  :BLOCKER: file("main.cpp") file("code.cpp") re-search("TODO")
  :END:
* TODO Commit Code to Repository

Or schedule the following task for an hour after the current task is
completed:

* TODO Put clothes in washer
  SCHEDULED: <2017-04-08 Sat 09:00>
  :PROPERTIES:
  :TRIGGER: next-sibling scheduled("++1h")
  :END:
* TODO Put clothes in dryer
  :PROPERTIES:
  :TRIGGER: next-sibling scheduled("++1h")
  :BLOCKER:  previous-sibling
  :END:

The (semi-complete) documentation is here:
http://www.nongnu.org/org-edna-el/

I'd appreciate some feedback on it, whether the code or the
documentation.

-- 
Ian Dunn