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

Re: [O] Export in Foswiki format?

[Nick Dokos]

"Loris Bennett"  writes:

> "Loris Bennett"  writes:
>
>> "Loris Bennett"  writes:
>>
>>> Hi,
>>>
>>> I'm interested in exporting from Org to Foswiki format.  Is
>>> org-export-generic.el still the way to go or has this been superseded by
>>> something else?
>>
>> Nevermind, I found this:
>>
>>   https://github.com/dfeich/org8-wikiexporters
>>
>> also available via MELPA.
>
> The following
>
>   M-x org-twiki-export-as-twiki
>
> worked on a file yesterday.  Today, with the same file, I get 
>
>   org-export-barf-if-invalid-backend: Unknown "nil" back-end: Aborting export
>
> Any ideas of what I might have accidentally tweaked to make things
> break?
>

Restarted your emacs and forgot to load ox-twiki.el?

-- 
Nick

Re: [O] Bug: export does not ignore #+INCLUDE if archived or tagged :noexport: Package: Org mode version 9.0.5 (9.0.5-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20170210/)

[Rasmus]

Stefan Kredler  writes:

> when archiving sections or exclude them from export I would expect
> them being exempt from being evaluated during export.
> The section archived or marked as ~:no export:~ is still evaluated and there 
> is an error
> if the reference in the include file is no longer available. I get the error 
> message
> ~"org-export-expand-include-keyword: Cannot include file ~/filename.org"~

IMO this is a feature.  I have used this before, for instance when
including tables used in source blocks at export time.

Rasmus

-- 
Dobbelt-A

Re: [O] Export in Foswiki format?

[Loris Bennett]

"Loris Bennett"  writes:

> "Loris Bennett"  writes:
>
>> Hi,
>>
>> I'm interested in exporting from Org to Foswiki format.  Is
>> org-export-generic.el still the way to go or has this been superseded by
>> something else?
>
> Nevermind, I found this:
>
>   https://github.com/dfeich/org8-wikiexporters
>
> also available via MELPA.

The following

  M-x org-twiki-export-as-twiki

worked on a file yesterday.  Today, with the same file, I get 

  org-export-barf-if-invalid-backend: Unknown "nil" back-end: Aborting export

Any ideas of what I might have accidentally tweaked to make things
break?

Cheers,

Loris

-- 
This signature is currently under construction.

Re: [O] Bug: Canceling a TODO state change does not revert the heading [9.0.5 (9.0.5-elpa @ /home/laurence/.emacs.d/elpa/org-20170210/)]

[Laurence Rochfort]

Nicolas Goaziou writes:

> I disagree. You may want to cancel the message because this change
> doesn't require one, but, yet, want the todo state change.

I see, that makes sense.

I notice that supplying an empty message with C-c C-k results in no
logbook entry at all. Is that intended behaviour too?

Cheers,
Laurence.

[O] Bug: export does not ignore #+INCLUDE if archived or tagged :noexport: Package: Org mode version 9.0.5 (9.0.5-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20170210/)

[Stefan Kredler]

when archiving sections or exclude them from export I would expect
them being exempt from being evaluated during export.
The section archived or marked as ~:no export:~ is still evaluated and there is 
an error
if the reference in the include file is no longer available. I get the error 
message
~"org-export-expand-include-keyword: Cannot include file ~/filename.org"~

-
MY PROJECTS -*- mode: org; -*-

* Heading
** sub
** Table to be ignored :noexport:
#+INCLUDE: filename.org::Table_to_ignore

* Archive :ARCHIVE:noexport:
** Table to be ignored :ARCHIVE:
#+INCLUDE: filename.org::Table_to_ignore
-

Emacs : GNU Emacs 24.5.1 (i686-pc-mingw32)
of 2015-04-11 on LEG570
Package: Org mode version 9.0.5 (9.0.5-elpaplus @ 
~/.emacs.d/elpa/org-plus-contrib-20170210/)
--

Stefan

Re: [O] Bug: link beginning with parenthesis doesn't work [9.0.5 (release_9.0.5-474-g942b62 @ /home/joe/org-mode/lisp/)]

[Nicolas Goaziou]

Hello,

Joe Corneli  writes:

> The (xxx) form for a link target, especially one outside of a block,
> doesn't seem to have meaning within the document model that Org
> understands.

Of course it does. It belongs to the link syntax. See, for example
`org-link-search' docstring. It could, however, be more visible in the
manual. In particular, it could be emphasized in both (info "(org)
Internal links") and (info "(org) External links"). Patch welcome !

> But I still think there is a legitimate bug report here, since the
> behaviour is not likely to be expected by the user.

Only if the user doesn't know about the syntax, which shouldn't happen
if the manual was great.

> Someone in my position has no interest in code refs, I was only trying
> to link to a bit of text in the buffer. Saying "oh but you can't link
> to this *one* kind of text" is perhaps a fair move. On the other hand,
> given that "following a link" just means "run a search process", that
> search process *could* be smart enough to notice that "no coderef was
> found, maybe the user meant to link to some plain text in
> parentheses". Then I wouldn't see an error.

But then, you wouldn't catch real, but mis-typed, coderef links. At
least, the error tells you something is wrong in the link syntax,
without creating false positives. So, I don't think this would be a net
gain overall.

Note that the same happens if your regular search text starts with an
asterisk. Org will understand you're looking after headlines only, which
may not be what you want. Ditto with the hash sign.

Org has some syntax for links, you need to know about it if you don't
want to get bitten. Hopefully, the manual could help you about it.


Regards,

-- 
Nicolas Goaziou