org-depend: dependencies between TODO entries in different files

org-depend: dependencies between TODO entries in different files

[Karl Voit]

Hi!

On [1] LinuxFag asked why org-depend.el does not work with
dependencies of headings in different Org-mode files. This is also a
very annoying limitation to me since I have many Org-mode files in
my org-agenda-files and I also don't want to limit myself to use
dependencies within a single file only.

I analyzed my situation in the code:

    Org-mode version 8.3.4 (release_8.3.4-33-gd522fc) 
    org-depend.el Version: 0.08

Function org-depend-block-todo uses org-find-entry-with-id (from
org.el) which is using org-find-property which starts with
(goto-char (point-min)) not jumping to any other org-mode buffer.


Is there a reason behind this design choice?

Who is the current maintainer of org-depend.el? Carsten ist listed
as author in the header.


[1] https://www.reddit.com/r/orgmode/comments/4za540/any_way_to_express_dependencies_between_todo/

-- 
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
       > get Memacs from https://github.com/novoid/Memacs <

https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github

Re: org-depend: dependencies between TODO entries in different files

[Nicolas Goaziou]

Hello,

Karl Voit <devnull@Karl-Voit.at> writes:

> On [1] LinuxFag asked why org-depend.el does not work with
> dependencies of headings in different Org-mode files. This is also a
> very annoying limitation to me since I have many Org-mode files in
> my org-agenda-files and I also don't want to limit myself to use
> dependencies within a single file only.
>
> I analyzed my situation in the code:
>
>     Org-mode version 8.3.4 (release_8.3.4-33-gd522fc) 
>     org-depend.el Version: 0.08
>
> Function org-depend-block-todo uses org-find-entry-with-id (from
> org.el) which is using org-find-property which starts with
> (goto-char (point-min)) not jumping to any other org-mode buffer.
>
>
> Is there a reason behind this design choice?

What design choice?

1. That `org-find-property' only searches in the current document?

2. That `org-depend-block-todo' uses `org-find-entry-with-id' instead of
   e.g., `org-id-find'?

Property API assumes properties are local to the document. When you
search for property "FOO", it means "FOO" in the current buffer, not
"FOO" is some other random Org file somewhere in your hard-disk.

ID property is special for that matter. Whenever Org sets such
a property, it updates a location database (which means ID properties
shouldn't be changed "manually"). So, ID property can efficiently be
used to refer to remote documents.

As a consequence, it may be useful to use `org-id-find' and fall-back to
`org-find-property' in `org-depend-block-todo'.

> Who is the current maintainer of org-depend.el? Carsten ist listed
> as author in the header.

I guess nobody. Do you want to take care of it?


Regards,

-- 
Nicolas Goaziou

Re: org-depend: dependencies between TODO entries in different files

[Karl Voit]

* Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
> Hello,

Hello Nicolas,

> Karl Voit <devnull@Karl-Voit.at> writes:
>
>> Function org-depend-block-todo uses org-find-entry-with-id (from
>> org.el) which is using org-find-property which starts with
>> (goto-char (point-min)) not jumping to any other org-mode buffer.
>>
>> Is there a reason behind this design choice?
>
> What design choice?

... that org-depend is using the current document only.

> 1. That `org-find-property' only searches in the current document?
>
> 2. That `org-depend-block-todo' uses `org-find-entry-with-id' instead of
>    e.g., `org-id-find'?
>
> Property API assumes properties are local to the document. When you
> search for property "FOO", it means "FOO" in the current buffer, not
> "FOO" is some other random Org file somewhere in your hard-disk.

Ah, good to know.

Is there a document, where someone is able to learn those
"meta-patterns" like "Property API assumes properties are local to
the document"?

> ID property is special for that matter. 

Clearly, when you take a look at "id:example-id".

> Whenever Org sets such a property, it updates a location database
> (which means ID properties shouldn't be changed "manually"). 

Being curious: since I only set IDs manually (by typing them into
the PROPERTIES drawer by myself), do I have to take care of
"updating some database"?

> So, ID property can efficiently be used to refer to remote
> documents.

... which I find ultimately useful to get a "personal wiki".

> As a consequence, it may be useful to use `org-id-find' and
> fall-back to `org-find-property' in `org-depend-block-todo'.
>
>> Who is the current maintainer of org-depend.el? Carsten ist
>> listed as author in the header.
>
> I guess nobody. Do you want to take care of it?

Trust me: with my very limited knowledge of Elisp and Org-mode
internals, you do not want to see a commit from my side that is
something other than a typo fix or documentation. ;-)

Can you do us the favour?

Thanks for your insight!

-- 
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
       > get Memacs from https://github.com/novoid/Memacs <

https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github

Re: org-depend: dependencies between TODO entries in different files

[Carsten Dominik]

[-- Attachment #1: Type: text/plain, Size: 2836 bytes --]

Hi,

I can take a look at that.  Unless Nicolas already is working on it, of
course.

One additional point is, of course, that org-depend is not part of the
core, but was written as a proof of concept.  Is anyone besides Karl using
it regularly?  I don't want to break anything by changing it.  Maybe it
would, in fact, be better to first look in the local file and then try
org-id-find.

Carsten

On Thu, Aug 25, 2016 at 5:11 PM, Karl Voit <devnull@karl-voit.at> wrote:

> * Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
> > Hello,
>
> Hello Nicolas,
>
> > Karl Voit <devnull@Karl-Voit.at> writes:
> >
> >> Function org-depend-block-todo uses org-find-entry-with-id (from
> >> org.el) which is using org-find-property which starts with
> >> (goto-char (point-min)) not jumping to any other org-mode buffer.
> >>
> >> Is there a reason behind this design choice?
> >
> > What design choice?
>
> ... that org-depend is using the current document only.
>
> > 1. That `org-find-property' only searches in the current document?
> >
> > 2. That `org-depend-block-todo' uses `org-find-entry-with-id' instead of
> >    e.g., `org-id-find'?
> >
> > Property API assumes properties are local to the document. When you
> > search for property "FOO", it means "FOO" in the current buffer, not
> > "FOO" is some other random Org file somewhere in your hard-disk.
>
> Ah, good to know.
>
> Is there a document, where someone is able to learn those
> "meta-patterns" like "Property API assumes properties are local to
> the document"?
>
> > ID property is special for that matter.
>
> Clearly, when you take a look at "id:example-id".
>
> > Whenever Org sets such a property, it updates a location database
> > (which means ID properties shouldn't be changed "manually").
>
> Being curious: since I only set IDs manually (by typing them into
> the PROPERTIES drawer by myself), do I have to take care of
> "updating some database"?
>
> > So, ID property can efficiently be used to refer to remote
> > documents.
>
> ... which I find ultimately useful to get a "personal wiki".
>
> > As a consequence, it may be useful to use `org-id-find' and
> > fall-back to `org-find-property' in `org-depend-block-todo'.
> >
> >> Who is the current maintainer of org-depend.el? Carsten ist
> >> listed as author in the header.
> >
> > I guess nobody. Do you want to take care of it?
>
> Trust me: with my very limited knowledge of Elisp and Org-mode
> internals, you do not want to see a commit from my side that is
> something other than a typo fix or documentation. ;-)
>
> Can you do us the favour?
>
> Thanks for your insight!
>
> --
> mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
>        > get Memacs from https://github.com/novoid/Memacs <
>
> https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on
> github
>
>
>

[-- Attachment #2: Type: text/html, Size: 4129 bytes --]

Re: org-depend: dependencies between TODO entries in different files

[Jorge Morais Neto]

On 8 December 2016 at 04:44, Carsten Dominik <dominik@uva.nl> wrote:
> One additional point is, of course, that org-depend is not part of the core,
> but was written as a proof of concept.  Is anyone besides Karl using it
> regularly?  I don't want to break anything by changing it.
I use it (in a very small number of entries).

Regards
-- 
• I am Brazilian.  I hope my English is correct and I welcome corrections.
• Please adopt free formats like PDF, ODF, Org, LaTeX, Opus, WebM and 7z.
• Free (as in free speech) software for Android: https://f-droid.org/

Re: org-depend: dependencies between TODO entries in different files

[Samuel Loury]

Jorge Morais Neto <jorge13515@gmail.com> writes:

> On 8 December 2016 at 04:44, Carsten Dominik <dominik@uva.nl> wrote:
>> One additional point is, of course, that org-depend is not part of the core,
>> but was written as a proof of concept.  Is anyone besides Karl using it
>> regularly?  I don't want to break anything by changing it.
> I use it (in a very small number of entries).

Me too. but I don't mind it to break.

-- 
Konubinix
GPG Key    : 7439106A
Fingerprint: 5993 BE7A DA65 E2D9 06CE  5C36 75D2 3CED 7439 106A

Re: org-depend: dependencies between TODO entries in different files

[Jorge Morais Neto]

On 8 December 2016 at 08:16, Jorge Morais Neto <jorge13515@gmail.com> wrote:
> On 8 December 2016 at 04:44, Carsten Dominik <dominik@uva.nl> wrote:
>> One additional point is, of course, that org-depend is not part of the core,
>> but was written as a proof of concept.  Is anyone besides Karl using it
>> regularly?  I don't want to break anything by changing it.
> I use it (in a very small number of entries).
I would like to add that, AFAIK, currently I only use org-depend to depend on
entries in the same Org document.  But someday I will probably want to depend
on entries in a different document.

Regards
-- 
• I am Brazilian.  I hope my English is correct and I welcome corrections.
• Please adopt free formats like PDF, ODF, Org, LaTeX, Opus, WebM and 7z.
• Free (as in free speech) software for Android: https://f-droid.org/

Re: org-depend: dependencies between TODO entries in different files

[Nicolas Goaziou]

Hello,

Carsten Dominik <dominik@uva.nl> writes:

> I can take a look at that.  Unless Nicolas already is working on it, of
> course.

It's somewhere on my (rather large) TODO list, but I'm not currently
working on it.

Regards,

-- 
Nicolas Goaziou

Re: org-depend: dependencies between TODO entries in different files

[Christophe Schockaert]

Carsten Dominik writes:

> Hi,
>
> I can take a look at that.  Unless Nicolas already is working on it, of
> course.
>
> [...]  Is anyone besides Karl using it regularly?  I don't want to
> break anything by changing it.
Hi Carsten,


I started to use it a few months ago, and I am using it more and more
when I have to gather a bunch of existing actions and give a follow-up
for such a subset. Or when I need to refer to a subaction not directly
related, before I can go further in a broader project.

As Karl, I do split dependencies across files, so this would be a nice
improvement.

I considered to give a try for making a change, but I know only very
basic ELisp, and I lack of time to experiment, so I lived with it. I
would be greatful if you would do it for us :)

And thank you Karl for asking !

> Maybe it would, in fact, be better to first look in the local file and
> then try org-id-find.
>
> Carsten
I like that idea.

Thank you for taking care of it (and for creating Org ^^),
Kind Regards,

Christophe

> On Thu, Aug 25, 2016 at 5:11 PM, Karl Voit <devnull@karl-voit.at> wrote:
>
>> * Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
>> > Hello,
>>
>> Hello Nicolas,
>>
>> > Karl Voit <devnull@Karl-Voit.at> writes:
>> >
>> >> Function org-depend-block-todo uses org-find-entry-with-id (from
>> >> org.el) which is using org-find-property which starts with
>> >> (goto-char (point-min)) not jumping to any other org-mode buffer.
>> >>
>> >> Is there a reason behind this design choice?
>> >
>> > What design choice?
>>
>> ... that org-depend is using the current document only.
>>
>> > 1. That `org-find-property' only searches in the current document?
>> >
>> > 2. That `org-depend-block-todo' uses `org-find-entry-with-id' instead of
>> >    e.g., `org-id-find'?
>> >
>> > Property API assumes properties are local to the document. When you
>> > search for property "FOO", it means "FOO" in the current buffer, not
>> > "FOO" is some other random Org file somewhere in your hard-disk.
>>
>> Ah, good to know.
>>
>> Is there a document, where someone is able to learn those
>> "meta-patterns" like "Property API assumes properties are local to
>> the document"?
>>
>> > ID property is special for that matter.
>>
>> Clearly, when you take a look at "id:example-id".
>>
>> > Whenever Org sets such a property, it updates a location database
>> > (which means ID properties shouldn't be changed "manually").
>>
>> Being curious: since I only set IDs manually (by typing them into
>> the PROPERTIES drawer by myself), do I have to take care of
>> "updating some database"?
>>
>> > So, ID property can efficiently be used to refer to remote
>> > documents.
>>
>> ... which I find ultimately useful to get a "personal wiki".
>>
>> > As a consequence, it may be useful to use `org-id-find' and
>> > fall-back to `org-find-property' in `org-depend-block-todo'.
>> >
>> >> Who is the current maintainer of org-depend.el? Carsten ist
>> >> listed as author in the header.
>> >
>> > I guess nobody. Do you want to take care of it?
>>
>> Trust me: with my very limited knowledge of Elisp and Org-mode
>> internals, you do not want to see a commit from my side that is
>> something other than a typo fix or documentation. ;-)
>>
>> Can you do us the favour?
>>
>> Thanks for your insight!
>>
>> --
>> mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
>>        > get Memacs from https://github.com/novoid/Memacs <
>>
>> https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on
>> github
>>
>>
>>


-- 
--------------->  mailto:R3vLibre@citadels.eu
Once it's perfectly aimed, the flying arrow goes straight to its target.
Thus, don't worry when things go right.
There will be enough time to worry about if they go wrong.
Then, it's time to fire a new arrow towards another direction.
Don't sink.  Adapt yourself !  The archer has to shoot accurately and quickly.
[Words of Erenthar, the bowman ranger] <---------------<<<<

Re: org-depend: dependencies between TODO entries in different files

[Karl Voit]

Hi,

* Christophe Schockaert <R3vLibre@citadels.eu> wrote:
>
> Carsten Dominik writes:
>
>> I can take a look at that.  Unless Nicolas already is working on it, of
>> course.
>>
>> [...]  Is anyone besides Karl using it regularly?  I don't want to
>> break anything by changing it.

Good point.

However, I don't think that there is a situation where
«ID-dependencies are found in all/agenda files» instead of
«ID-dependencies are found only within the same file» does break a
workflow. Using ID-dependencies from another file simply result in
false behavior in the current situation and not in a different
behavior.

Just my 2 cents.

> I started to use it a few months ago, and I am using it more and more
> when I have to gather a bunch of existing actions and give a follow-up
> for such a subset. Or when I need to refer to a subaction not directly
> related, before I can go further in a broader project.

I am using it heavily to implement workflows I could not do
otherwise: TRIGGER and BLOCKER.

For me, org-depend functionality was the reason to begin with
org-mode in the first place. And it is still one of my top three
org-mode features. When I show org-depend in my org-mode workshops,
I still get very positive feedback.

> And thank you Karl for asking !

You're welcome.

-- 
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
       > get Memacs from https://github.com/novoid/Memacs <

https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github

Re: org-depend: dependencies between TODO entries in different files

[Carsten Dominik]

[-- Attachment #1: Type: text/plain, Size: 2334 bytes --]

Dear all,

thanks for your feedback.

Since ord-depend was only proof of concept, we could also think a bit more
broadly about what it should be able to do.  Is there specific
functionality it also should support, besides the TRIGGER/BLOCKER functions
it has right now?

One issue to deal with is, that in different files, a different set of TODO
keywords might be active, so if a TRIGGER entry changes a TODO state, and
that entry lives in a different file, it falls onto the user to make sure
that the required state is valid in both files.

Any ides what is missing or might be useful?

Carsten

On Mon, Dec 12, 2016 at 12:57 PM, Karl Voit <devnull@karl-voit.at> wrote:

> Hi,
>
> * Christophe Schockaert <R3vLibre@citadels.eu> wrote:
> >
> > Carsten Dominik writes:
> >
> >> I can take a look at that.  Unless Nicolas already is working on it, of
> >> course.
> >>
> >> [...]  Is anyone besides Karl using it regularly?  I don't want to
> >> break anything by changing it.
>
> Good point.
>
> However, I don't think that there is a situation where
> «ID-dependencies are found in all/agenda files» instead of
> «ID-dependencies are found only within the same file» does break a
> workflow. Using ID-dependencies from another file simply result in
> false behavior in the current situation and not in a different
> behavior.
>
> Just my 2 cents.
>
> > I started to use it a few months ago, and I am using it more and more
> > when I have to gather a bunch of existing actions and give a follow-up
> > for such a subset. Or when I need to refer to a subaction not directly
> > related, before I can go further in a broader project.
>
> I am using it heavily to implement workflows I could not do
> otherwise: TRIGGER and BLOCKER.
>
> For me, org-depend functionality was the reason to begin with
> org-mode in the first place. And it is still one of my top three
> org-mode features. When I show org-depend in my org-mode workshops,
> I still get very positive feedback.
>
> > And thank you Karl for asking !
>
> You're welcome.
>
> --
> mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
>        > get Memacs from https://github.com/novoid/Memacs <
>
> https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on
> github
>
>
>

[-- Attachment #2: Type: text/html, Size: 3280 bytes --]

Re: org-depend: dependencies between TODO entries in different files

[Karl Voit]

* Carsten Dominik <dominik@uva.nl> wrote:
>
> Dear all,

Hi Carsten,

> Since ord-depend was only proof of concept, we could also think a bit more
> broadly about what it should be able to do.  Is there specific
> functionality it also should support, besides the TRIGGER/BLOCKER functions
> it has right now?

Oh my goodness - free wishes for org-depend? Christmas is rather
early this year! ;-)

OK, let's do some brain storming ...

For reference purposes: http://orgmode.org/worg/org-contrib/org-depend.html

> One issue to deal with is, that in different files, a different set of TODO
> keywords might be active, so if a TRIGGER entry changes a TODO state, and
> that entry lives in a different file, it falls onto the user to make sure
> that the required state is valid in both files.

From my point of view: due to the fact that the user has to state
the TRIGGER keyword manually, it is up to the user that this makes
any sense. So far, nothing prevents me from typing:

    :TRIGGER: foo-bar(INVALIDSTATUS)


> Any ides what is missing or might be useful?

Well, this comes a bit unprepared (I might be able to come up with
more feature possibilities to org-depend when thinking about it) but
I'd say that following workflows would be nice to discuss about:


Being able to specify SCHEDULED-dates *and* next status for
arbitrary IDs.

For example:

    ** NEXT Asking the client about XY
    :PROPERTIES:
    :TRIGGER: send-task(NEXT,2016-12-23)
    :END:
    
    ** Send XY to client
    :PROPERTIES:
    :ID: send-task
    :END:

Well the syntax might be chosen differently. What I want to achieve
is that when changing the "Asking" task to a finished state, the
"Send" task gets a fixed SCHEDULED value and the status NEXT. 

Additional: the two tasks are not necessarily in the same file or
within the same sub-hierarchy. So the «inherit scheduled date»
feature via chain-siblings-scheduled does not work in most cases to
me.


Another one:

    ** NEXT Asking the client about XY
    SCHEDULED: <2016-12-12>
    :PROPERTIES:
    :TRIGGER: send-task(NEXT,.+3d)
    :END:
    
    ** Send XY to client
    :PROPERTIES:
    :ID: send-task
    :END:

When the "Asking" task is set to a finished state, the "Send" task
will be scheduled three days in the future and gets the status NEXT.

The usual date-syntax applies here as well: +3d (3 days from maybe
the SCHEDULED(?) date of the "Asking" task), .+3d (3 days from now),
and so forth.


Another one: having the possibility to define "Send" state changes
that rely on the "Asking" state. For example: If I cancel the
"Asking" task, the "Send" state should be cancelled as well because
it makes no sense without the first one.

-- 
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
       > get Memacs from https://github.com/novoid/Memacs <

https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github

Re: org-depend: dependencies between TODO entries in different files

[Christophe Schockaert]

Hi all,


Karl Voit writes:
> Oh my goodness - free wishes for org-depend? Christmas is rather
> early this year! ;-)
Indeed, that's wonderful ^^

> OK, let's do some brain storming ...
As a summary from my sight point, I am totally inline with Karl for the
feature set:

  - Personnally, I am ready to care about state consistency myself, so
    letting the user responsible for it
  
  - Same wish about scheduling arbitrary actions by making use of IDs:
    either absolute or relative
  
  - I would also have use of different state transitions: DONE => TODO ;
    CANCELLED => CANCELLED


Besides that, I wonder if/how we could automate the following course of
actions:

  - let have point on an entry
  
  - create a new "TODO-like" entry as a link to that entry
  
  - assign an ID to both entries: lets say "ID-original" and "ID-duplicate"
    
  - in the new entry: define a BLOCKER property set on "ID-original"

  - in the original entry: define a TRIGGER property set as
    ID-duplicate(DONE)


At first sight:

- the new entry could be created besides the original or in a file where
  it is ready to refile

- the TODO state in the new entry could be set with a default, I think
  it is so easy to switch afterwards with Org keystrokes

- the triggered state might better be a parameter (possibly a customized
  default as "TODO"): otherwise, it would be necessary to go inside the
  drawer to change it


Currently, I am doing all this manually, quite often. I am not sure if a
capture template can offer that. It's on my plan to look after it for
some time, but I didn't do it yet. The tricky part is the cross-link
creation and storage. So, as we are discussion on the topic, I just
share what is on my mind about it :)

I wish it can bring something useful,
Feedbacks are welcome,


Christophe

-- 
--------------->  mailto:R3vLibre@citadels.eu
Once it's perfectly aimed, the flying arrow goes straight to its target.
Thus, don't worry when things go right.
There will be enough time to worry about if they go wrong.
Then, it's time to fire a new arrow towards another direction.
Don't sink.  Adapt yourself !  The archer has to shoot accurately and quickly.
[Words of Erenthar, the bowman ranger] <---------------<<<<

org-depend improvements: ID picker

[Karl Voit]

* Karl Voit <devnull@Karl-Voit.at> wrote:
> * Carsten Dominik <dominik@uva.nl> wrote:
>
>> Since ord-depend was only proof of concept, we could also think a bit more
>> broadly about what it should be able to do.  Is there specific
>> functionality it also should support, besides the TRIGGER/BLOCKER functions
>> it has right now?
>
> Oh my goodness - free wishes for org-depend? Christmas is rather
> early this year! ;-)
>
> For reference purposes: http://orgmode.org/worg/org-contrib/org-depend.html

I thought about some org-depend improvements to take it to the next
level.

Since many Org-mode users do not know or use org-depend.el, I
decided to write a blog post about it and how improvements can easy
my digital life:

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

Some improvements are probably solved with a few lines of Elisp code.
Unfortunately, I am very bad at coding Elisp myself and thus can't
extend Emacs the way I would love to.

For discussion purposes, I now append the improvements as separate
mailinglist emails here as well:

---------------------

1 Improvement: ID Picker
========================

  First of all, I'd like to see some kind of ID picker when defining
  `:TRIGGER:' and `:BLOCKER:' dependencies.

  This should work like this: after setting up the task in headings and
  giving them IDs, I'd like to invoke a "I want to define a
  dependency"-command. It first asks me what property I want to set:
  `:TRIGGER:' or `:BLOCKER:'.

  Then I get asked to select any ID which could be found within the same
  sub-hierarchy (or even in all files?).

  After being asked for the KEYWORD to be set for `:TRIGGER:'
  dependencies (if applicable), the property is added to the current
  heading accordingly.

  This would drastically improve creating dependency definitions and
  prevent typing errors in the first place.


-- 
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
       > get Memacs from https://github.com/novoid/Memacs <

https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github

Re: org-depend improvements: ID picker

[Eric Abrahamsen]

Karl Voit <devnull@Karl-Voit.at> writes:

> * Karl Voit <devnull@Karl-Voit.at> wrote:
>> * Carsten Dominik <dominik@uva.nl> wrote:
>>
>>> Since ord-depend was only proof of concept, we could also think a bit more
>>> broadly about what it should be able to do.  Is there specific
>>> functionality it also should support, besides the TRIGGER/BLOCKER functions
>>> it has right now?

[...]

> 1 Improvement: ID Picker
> ========================
>
>   First of all, I'd like to see some kind of ID picker when defining
>   `:TRIGGER:' and `:BLOCKER:' dependencies.
>
>   This should work like this: after setting up the task in headings and
>   giving them IDs, I'd like to invoke a "I want to define a
>   dependency"-command. It first asks me what property I want to set:
>   `:TRIGGER:' or `:BLOCKER:'.
>
>   Then I get asked to select any ID which could be found within the same
>   sub-hierarchy (or even in all files?).
>
>   After being asked for the KEYWORD to be set for `:TRIGGER:'
>   dependencies (if applicable), the property is added to the current
>   heading accordingly.
>
>   This would drastically improve creating dependency definitions and
>   prevent typing errors in the first place.

I like this a lot, for more uses than just org-depend, and it would be
very easy to implement. We've got `org-property-set-functions-alist' for
using special functions to read the values of special properties, and
we've got `org-id-get-with-outline-(drilling|path-completion), so it's
pretty much already done!


(defun my-trigger-property-prompt ()
  (when (derived-mode-p 'org-mode)
    (let ((id (org-id-get-with-outline-drilling))
	  (kw (org-completing-read "Keyword: " org-todo-keywords-1)))
      (do-something-with-id-and-kw))))

(push '("TRIGGER" . my-trigger-property-prompt)
      org-property-set-functions-alist)

I don't actually know how the TRIGGER property is meant to be formatted
(and I didn't really test the above), but something very near to the
above should do what you want.

Eric

Re: a general ID picker

[Karl Voit]

* Eric Abrahamsen <eric@ericabrahamsen.net> wrote:
> Karl Voit <devnull@Karl-Voit.at> writes:
>
>> 1 Improvement: ID Picker
>> ========================
>>
>>   First of all, I'd like to see some kind of ID picker when defining
>>   `:TRIGGER:' and `:BLOCKER:' dependencies.
>>
>>   This should work like this: after setting up the task in headings and
>>   giving them IDs, I'd like to invoke a "I want to define a
>>   dependency"-command. It first asks me what property I want to set:
>>   `:TRIGGER:' or `:BLOCKER:'.
>>
>>   Then I get asked to select any ID which could be found within the same
>>   sub-hierarchy (or even in all files?).
>>
>>   After being asked for the KEYWORD to be set for `:TRIGGER:'
>>   dependencies (if applicable), the property is added to the current
>>   heading accordingly.
>>
>>   This would drastically improve creating dependency definitions and
>>   prevent typing errors in the first place.
>
> I like this a lot, for more uses than just org-depend, and it would be
> very easy to implement. We've got `org-property-set-functions-alist' for
> using special functions to read the values of special properties, and
> we've got `org-id-get-with-outline-(drilling|path-completion), so it's
> pretty much already done!
>
> (defun my-trigger-property-prompt ()
>   (when (derived-mode-p 'org-mode)
>     (let ((id (org-id-get-with-outline-drilling))
> 	  (kw (org-completing-read "Keyword: " org-todo-keywords-1)))
>       (do-something-with-id-and-kw))))
>
> (push '("TRIGGER" . my-trigger-property-prompt)
>       org-property-set-functions-alist)
>
> I don't actually know how the TRIGGER property is meant to be formatted
> (and I didn't really test the above), but something very near to the
> above should do what you want.

Well, I am afraid that I am totally lost when it comes to "pretty
much already done". The great Professor Kitchin helped me with a
sophisticated function and sent me the "almost finished" code and I
failed at making it run :-(

However, I do tend to think that the ID picker would be of general
interest and I'd like to see it in the global Org-mode featureset
for multiple purposes, not only defining org-depend dependencies.

-- 
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
       > get Memacs from https://github.com/novoid/Memacs <

https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github

Re: a general ID picker

[Eric Abrahamsen]

Karl Voit <devnull@Karl-Voit.at> writes:

> * Eric Abrahamsen <eric@ericabrahamsen.net> wrote:
>> Karl Voit <devnull@Karl-Voit.at> writes:
>>
>>> 1 Improvement: ID Picker
>>> ========================
>>>
>>>   First of all, I'd like to see some kind of ID picker when defining
>>>   `:TRIGGER:' and `:BLOCKER:' dependencies.
>>>
>>>   This should work like this: after setting up the task in headings and
>>>   giving them IDs, I'd like to invoke a "I want to define a
>>>   dependency"-command. It first asks me what property I want to set:
>>>   `:TRIGGER:' or `:BLOCKER:'.
>>>
>>>   Then I get asked to select any ID which could be found within the same
>>>   sub-hierarchy (or even in all files?).
>>>
>>>   After being asked for the KEYWORD to be set for `:TRIGGER:'
>>>   dependencies (if applicable), the property is added to the current
>>>   heading accordingly.
>>>
>>>   This would drastically improve creating dependency definitions and
>>>   prevent typing errors in the first place.
>>
>> I like this a lot, for more uses than just org-depend, and it would be
>> very easy to implement. We've got `org-property-set-functions-alist' for
>> using special functions to read the values of special properties, and
>> we've got `org-id-get-with-outline-(drilling|path-completion), so it's
>> pretty much already done!
>>
>> (defun my-trigger-property-prompt ()
>>   (when (derived-mode-p 'org-mode)
>>     (let ((id (org-id-get-with-outline-drilling))
>> 	  (kw (org-completing-read "Keyword: " org-todo-keywords-1)))
>>       (do-something-with-id-and-kw))))
>>
>> (push '("TRIGGER" . my-trigger-property-prompt)
>>       org-property-set-functions-alist)
>>
>> I don't actually know how the TRIGGER property is meant to be formatted
>> (and I didn't really test the above), but something very near to the
>> above should do what you want.
>
> Well, I am afraid that I am totally lost when it comes to "pretty
> much already done". The great Professor Kitchin helped me with a
> sophisticated function and sent me the "almost finished" code and I
> failed at making it run :-(
>
> However, I do tend to think that the ID picker would be of general
> interest and I'd like to see it in the global Org-mode featureset
> for multiple purposes, not only defining org-depend dependencies.

Ha, sorry, I'll actually look at org-depend...

...okay, so it looks like the :TRIGGER: property can contain several
different types of values. But from your message you seem to be talking
about this kind:

some-other-headings-id-df83454(NEXT)

So the code you'd want would be (I actually tested it this time):

(defun my-trigger-property-prompt (&rest args)
  (when (derived-mode-p 'org-mode)
    (let ((id (org-id-get-with-outline-path-completion))
	  (kw (org-completing-read "Keyword: " org-todo-keywords-1 nil nil)))
      (format "%s(%s)" id kw))))

(push '("TRIGGER" . my-trigger-property-prompt)
      org-property-set-functions-alist)

I switched from `org-id-get-with-outline-drilling', as that raised an
error about `org-goto-map' being an undefined variable (lexical scoping
issue?). Also, this only does the one kind of TRIGGER format. Also it is
limited to completing on the TODO keywords defined in the current file,
but will accept others.

In short, it's got lots of limitations, but please do eval the above and
see if it works, then we can go from there.

Eric

Automatically Generating IDs From Title and Date

[Karl Voit]

* Karl Voit <devnull@Karl-Voit.at> wrote:
> * Carsten Dominik <dominik@uva.nl> wrote:
>
>> Since ord-depend was only proof of concept, we could also think a bit more
>> broadly about what it should be able to do.  Is there specific
>> functionality it also should support, besides the TRIGGER/BLOCKER functions
>> it has right now?
>
> Oh my goodness - free wishes for org-depend? Christmas is rather
> early this year! ;-)
>
> For reference purposes: http://orgmode.org/worg/org-contrib/org-depend.html

I thought about some org-depend improvements to take it to the next
level.

Since many Org-mode users do not know or use org-depend.el, I
decided to write a blog post about it and how improvements can easy
my digital life:

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

Some improvements are probably solved with a few lines of Elisp code.
Unfortunately, I am very bad at coding Elisp myself and thus can't
extend Emacs the way I would love to.

For discussion purposes, I now append the improvements as separate
mailinglist emails here as well:

---------------------


2 Improvement: Generating IDs From Heading and Date
===================================================

  So far, I define `:ID:' properties manually. There are settings that
  result in random IDs set for any new heading. I don't like random ID
  numbers because I would like to get a hint what heading this might be
  when I see it.

  Usually, my IDs start with the current ISO day to enforce uniqueness
  and look like this:

   *Title*                               *Manual ID*
  -----------------------------------------------------------------------
   Update notebook                       2016-12-18-update-notebook
   Schedule a meeting with Bob           2016-12-18-schedule-meeting-bob
   Add additional URLs to lecture notes  2016-12-18-add-URLs-to-lecture

  Wouldn't it be nice when there is a command which takes the current
  heading title and auto-generates the ID property accordingly? I guess
  this is not that hard to do:

   *Title*                               *Auto-generated ID*
  ---------------------------------------------------------------------------------------
   Update notebook                       2016-12-18-Update-notebook
   Schedule a meeting with Bob           2016-12-18-Schedule-a-meeting-with-Bob
   Add additional URLs to lecture notes  2016-12-18-Add-additional-URLs-to-lecture-notes



-- 
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
       > get Memacs from https://github.com/novoid/Memacs <

https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github

Re: Automatically Generating IDs From Title and Date

[Samuel Wales]

On 12/18/16, Karl Voit <devnull@karl-voit.at> wrote:
>   Usually, my IDs start with the current ISO day to enforce uniqueness
>   and look like this:

my understanding, which might be incorrect, is that custom id is for
human-readable purposes, while id is for uuid.  although you could
prepend to uuid.

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com

The disease DOES progress.  MANY people have died from it.  And
ANYBODY can get it.

Denmark: free Karina Hansen NOW.
  UPDATE 2016-10: home, but not fully free

Properties ID vs. CUSTOM_ID (was: Automatically Generating IDs From Title and Date)

[Karl Voit]

* Samuel Wales <samologist@gmail.com> wrote:
> On 12/18/16, Karl Voit <devnull@karl-voit.at> wrote:
>>   Usually, my IDs start with the current ISO day to enforce uniqueness
>>   and look like this:
>
> my understanding, which might be incorrect, is that custom id is for
> human-readable purposes, while id is for uuid.  although you could
> prepend to uuid.

There once was a discussion on this topic here:
https://lists.gnu.org/archive/html/emacs-orgmode/2016-08/msg00165.html

I am a bit worried: So far, I got 125870 manually set ID properties
in my Org-mode files. 

To me, using :ID: was straight forward since I never read about any
other ID when I began with Org-mode in 2011.

Many features required me to have an :ID: and no feature I stumbled
upon required me to have something else as reference:
id:this-is-an-id, making references using org-store-link, and so
forth.

So let's search through the manual:
    http://orgmode.org/org.html#Internal-links
    http://orgmode.org/org.html#Handling-links
    http://orgmode.org/org.html#Search-options

Well, either this did not exist in 2011 or I was not paying
attention. I never faced any disadvantage, using ID properties
instead.

Do I really need to migrate and risk broken links? Or is there a
safe way to move to CUSTOM_ID?

Are there advantages when I switch to CUSTOM_IDs?

Do I really have to have a CUSTOM_ID *and* an ID set for being able
to reference any heading via human-readable ids *and* features like
org-store-link and so on?

-- 
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
       > get Memacs from https://github.com/novoid/Memacs <

https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github

Re: Properties ID vs. CUSTOM_ID (was: Automatically Generating IDs From Title and Date)

[Karl Voit]

* Karl Voit <devnull@Karl-Voit.at> wrote:
> * Samuel Wales <samologist@gmail.com> wrote:
>> On 12/18/16, Karl Voit <devnull@karl-voit.at> wrote:
>>>   Usually, my IDs start with the current ISO day to enforce uniqueness
>>>   and look like this:
>>
>> my understanding, which might be incorrect, is that custom id is for
>> human-readable purposes, while id is for uuid.  although you could
>> prepend to uuid.
>
> To me, using :ID: was straight forward since I never read about any
> other ID when I began with Org-mode in 2011.

Another argument:

According to 
http://orgmode.org/worg/org-contrib/org-depend.html
I have to use :ID: properties and not :CUSTOM_ID: properties.

,----[ task with dependency to a generated ID ]
| ** TODO a task
| :PROPERTIES:
| :BLOCKER: 6347hsfdl387ns43
| :ID:
`----

... in comparison to:

,----[ task with dependency to a manually written ID ]
| ** TODO a task
| :PROPERTIES:
| :BLOCKER: contacting-customer-XY
| :ID:
`----

I prefer the example with the manually written ID since it is human
readable.

-- 
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
       > get Memacs from https://github.com/novoid/Memacs <

https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github

Re: Properties ID vs. CUSTOM_ID (was: Automatically Generating IDs From Title and Date)

[John Kitchin]

[-- Attachment #1: Type: text/plain, Size: 1759 bytes --]

There is not an issue using a human-readable id in :ID: as long as it is
unique. It will store fine, link fine, etc...

John

-----------------------------------
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu


On Thu, Dec 22, 2016 at 5:03 AM, Karl Voit <devnull@karl-voit.at> wrote:

> * Karl Voit <devnull@Karl-Voit.at> wrote:
> > * Samuel Wales <samologist@gmail.com> wrote:
> >> On 12/18/16, Karl Voit <devnull@karl-voit.at> wrote:
> >>>   Usually, my IDs start with the current ISO day to enforce uniqueness
> >>>   and look like this:
> >>
> >> my understanding, which might be incorrect, is that custom id is for
> >> human-readable purposes, while id is for uuid.  although you could
> >> prepend to uuid.
> >
> > To me, using :ID: was straight forward since I never read about any
> > other ID when I began with Org-mode in 2011.
>
> Another argument:
>
> According to
> http://orgmode.org/worg/org-contrib/org-depend.html
> I have to use :ID: properties and not :CUSTOM_ID: properties.
>
> ,----[ task with dependency to a generated ID ]
> | ** TODO a task
> | :PROPERTIES:
> | :BLOCKER: 6347hsfdl387ns43
> | :ID:
> `----
>
> ... in comparison to:
>
> ,----[ task with dependency to a manually written ID ]
> | ** TODO a task
> | :PROPERTIES:
> | :BLOCKER: contacting-customer-XY
> | :ID:
> `----
>
> I prefer the example with the manually written ID since it is human
> readable.
>
> --
> mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
>        > get Memacs from https://github.com/novoid/Memacs <
>
> https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on
> github
>
>
>

[-- Attachment #2: Type: text/html, Size: 3044 bytes --]

Re: Properties ID vs. CUSTOM_ID

[Karl Voit]

* John Kitchin <jkitchin@andrew.cmu.edu> wrote:
>
> There is not an issue using a human-readable id in :ID: as long as it is
> unique. It will store fine, link fine, etc...

I also think so because I am only using human-readable :ID: without
any issue so far.

However, the argument was that no human should set :ID: but use
:CUSTOM_ID: *instead*. See also the old thread I linked before.

I'd prefer using manually written :ID: instead since migration would
not be trivial to me.

-- 
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
       > get Memacs from https://github.com/novoid/Memacs <

https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github

Re: Properties ID vs. CUSTOM_ID

[John Kitchin]

[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]

That is just be a convention though, and as long as the IDs are unique, it
does not matter who sets them.

John

-----------------------------------
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu


On Thu, Dec 22, 2016 at 10:30 AM, Karl Voit <devnull@karl-voit.at> wrote:

> * John Kitchin <jkitchin@andrew.cmu.edu> wrote:
> >
> > There is not an issue using a human-readable id in :ID: as long as it is
> > unique. It will store fine, link fine, etc...
>
> I also think so because I am only using human-readable :ID: without
> any issue so far.
>
> However, the argument was that no human should set :ID: but use
> :CUSTOM_ID: *instead*. See also the old thread I linked before.
>
> I'd prefer using manually written :ID: instead since migration would
> not be trivial to me.
>
> --
> mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
>        > get Memacs from https://github.com/novoid/Memacs <
>
> https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on
> github
>
>
>

[-- Attachment #2: Type: text/html, Size: 2113 bytes --]

Re: Properties ID vs. CUSTOM_ID

[Christophe Schockaert]

John Kitchin writes:
> On Thu, Dec 22, 2016 at 10:30 AM, Karl Voit <devnull@karl-voit.at> wrote:
>
>> * John Kitchin <jkitchin@andrew.cmu.edu> wrote:
>> >
>> > There is not an issue using a human-readable id in :ID: as long as it is
>> > unique. It will store fine, link fine, etc...
>>
>> I also think so because I am only using human-readable :ID: without
>> any issue so far.
>>
>> However, the argument was that no human should set :ID: but use
>> :CUSTOM_ID: *instead*. See also the old thread I linked before.
>>
> That is just be a convention though, and as long as the IDs are unique, it
> does not matter who sets them.
>
> John
That's how I ended up understanding their use.

When I read the manual (http://orgmode.org/manual/Handling-links.html),
it's actually possible to define both IDs for the same entry:

:  So using this command (added: org-store-link) in Org buffers will
:  potentially create two links: a human-readable from the custom ID, and
:  one that is globally unique and works even if the entry is moved from
:  file to file. Later, when inserting the link, you need to decide which
:  one to use.

Indeed, if both IDs are available, when inserting the link, we can
choose which ID will be used as target.

Also, we should note that the scope for CUSTOM_ID is the current file
only. That's what prevented me to migrate human readable IDs to
CUSTOM_IDs, and led me to consider the choice between the two as a
convention.

And I guess, that you would need ID available between different files
too, Karl, as you expect org-depend to be usable accross different files
:o)

Christophe

-- 
--------------->  mailto:R3vLibre@citadels.eu
Once it's perfectly aimed, the flying arrow goes straight to its target.
Thus, don't worry when things go right.
There will be enough time to worry about if they go wrong.
Then, it's time to fire a new arrow towards another direction.
Don't sink.  Adapt yourself !  The archer has to shoot accurately and quickly.
[Words of Erenthar, the bowman ranger] <---------------<<<<

Re: Properties ID vs. CUSTOM_ID

[Eric Abrahamsen]

Karl Voit <devnull@Karl-Voit.at> writes:

> * John Kitchin <jkitchin@andrew.cmu.edu> wrote:
>>
>> There is not an issue using a human-readable id in :ID: as long as it is
>> unique. It will store fine, link fine, etc...
>
> I also think so because I am only using human-readable :ID: without
> any issue so far.
>
> However, the argument was that no human should set :ID: but use
> :CUSTOM_ID: *instead*. See also the old thread I linked before.
>
> I'd prefer using manually written :ID: instead since migration would
> not be trivial to me.

You could also use the `org-property-set-functions-alist' trick with the
:ID: property. If you added an "ID" entry to that alist, Org's usual
automatic id creation would be unaffected, but if you set ID manually,
you could write a function that would first prompt for your
human-readable string, then check for ID uniqueness and append random
characters to your string until it was unique. I think that would be a
nice addition to org-id.el.

Eric

Re: Properties ID vs. CUSTOM_ID

[Christophe Schockaert]

Eric Abrahamsen writes:

> Karl Voit <devnull@Karl-Voit.at> writes:
>
>> I'd prefer using manually written :ID: instead since migration would
>> not be trivial to me.
>
> You could also use the `org-property-set-functions-alist' trick with the
> :ID: property. If you added an "ID" entry to that alist, Org's usual
> automatic id creation would be unaffected, but if you set ID manually,
> you could write a function that would first prompt for your
> human-readable string, then check for ID uniqueness and append random
> characters to your string until it was unique. I think that would be a
> nice addition to org-id.el.
>
> Eric
I thikn the tricky part would be that we can only ensure ID uniqueness
for the current agenda at the time of the ID creation. What if we later
merge another set of files where ID were created independantly to our
acustomed agenda files ?

I like the idea of assigning a date since we would reduce chances to
define at the same time the same string and the same day. If meticulous,
we could assign a date and a time or random string as you suggest, Eric
(a tiny UUID :).

I think I read somewhere the first inactive timestamp could be used to
tag an entry with a date. At least, I do that frequently.

Thus, if available, we could even use it as a date when creating the ID
in order to have an indication of the creation time for the heading
instead of creation time of the link.

Here it is for my suggestions.

Dates might not be appropriate for every situation, though...


Christophe
-- 
--------------->  mailto:R3vLibre@citadels.eu
Once it's perfectly aimed, the flying arrow goes straight to its target.
Thus, don't worry when things go right.
There will be enough time to worry about if they go wrong.
Then, it's time to fire a new arrow towards another direction.
Don't sink.  Adapt yourself !  The archer has to shoot accurately and quickly.
[Words of Erenthar, the bowman ranger] <---------------<<<<

Re: Properties ID vs. CUSTOM_ID

[Eric Abrahamsen]

Christophe Schockaert <R3vLibre@citadels.eu> writes:

> Eric Abrahamsen writes:
>
>> Karl Voit <devnull@Karl-Voit.at> writes:
>>
>>> I'd prefer using manually written :ID: instead since migration would
>>> not be trivial to me.
>>
>> You could also use the `org-property-set-functions-alist' trick with the
>> :ID: property. If you added an "ID" entry to that alist, Org's usual
>> automatic id creation would be unaffected, but if you set ID manually,
>> you could write a function that would first prompt for your
>> human-readable string, then check for ID uniqueness and append random
>> characters to your string until it was unique. I think that would be a
>> nice addition to org-id.el.
>>
>> Eric
> I thikn the tricky part would be that we can only ensure ID uniqueness
> for the current agenda at the time of the ID creation. What if we later
> merge another set of files where ID were created independantly to our
> acustomed agenda files ?
>
> I like the idea of assigning a date since we would reduce chances to
> define at the same time the same string and the same day. If meticulous,
> we could assign a date and a time or random string as you suggest, Eric
> (a tiny UUID :).
>
> I think I read somewhere the first inactive timestamp could be used to
> tag an entry with a date. At least, I do that frequently.
>
> Thus, if available, we could even use it as a date when creating the ID
> in order to have an indication of the creation time for the heading
> instead of creation time of the link.
>
> Here it is for my suggestions.
>
> Dates might not be appropriate for every situation, though...

I think including some sort of timestamp in the id would likely solve
the problem of future conflicts. I don't think adding the actual date
into the ID string would be that useful (how often would you be
comparing dates from the ID property?), but the human-readable string
could have a hash of the string plus (current-time) appended to it. Or,
perhaps better, a hash of the outline path plus current-time.

E

Re: Properties ID vs. CUSTOM_ID

[Carsten Dominik]

[-- Attachment #1: Type: text/plain, Size: 3184 bytes --]

Dear all,

before continuing this discussion, and before reinventing, you might want
to take a look at how org-id.el currently does create unique IDs.  In
particular, take a look at these variables:

org-id-prefix
org-id-method
org-id-include-domain

In particular, the docstring of the variable org-id-method is

  "The method that should be used to create new IDs.

An ID will consist of the optional prefix specified in `org-id-prefix',
and a unique part created by the method this variable specifies.

Allowed values are:

org        Org's own internal method, using an encoding of the current time
to
           microsecond accuracy, and optionally the current domain of the
           computer.  See the variable `org-id-include-domain'.

uuid       Create random (version 4) UUIDs.  If the program defined in
           `org-id-uuid-program' is available it is used to create the ID.
           Otherwise an internal functions is used."



Hope this helps.

Carsten


On Thu, Dec 22, 2016 at 10:02 PM, Eric Abrahamsen <eric@ericabrahamsen.net>
wrote:

> Christophe Schockaert <R3vLibre@citadels.eu> writes:
>
> > Eric Abrahamsen writes:
> >
> >> Karl Voit <devnull@Karl-Voit.at> writes:
> >>
> >>> I'd prefer using manually written :ID: instead since migration would
> >>> not be trivial to me.
> >>
> >> You could also use the `org-property-set-functions-alist' trick with
> the
> >> :ID: property. If you added an "ID" entry to that alist, Org's usual
> >> automatic id creation would be unaffected, but if you set ID manually,
> >> you could write a function that would first prompt for your
> >> human-readable string, then check for ID uniqueness and append random
> >> characters to your string until it was unique. I think that would be a
> >> nice addition to org-id.el.
> >>
> >> Eric
> > I thikn the tricky part would be that we can only ensure ID uniqueness
> > for the current agenda at the time of the ID creation. What if we later
> > merge another set of files where ID were created independantly to our
> > acustomed agenda files ?
> >
> > I like the idea of assigning a date since we would reduce chances to
> > define at the same time the same string and the same day. If meticulous,
> > we could assign a date and a time or random string as you suggest, Eric
> > (a tiny UUID :).
> >
> > I think I read somewhere the first inactive timestamp could be used to
> > tag an entry with a date. At least, I do that frequently.
> >
> > Thus, if available, we could even use it as a date when creating the ID
> > in order to have an indication of the creation time for the heading
> > instead of creation time of the link.
> >
> > Here it is for my suggestions.
> >
> > Dates might not be appropriate for every situation, though...
>
> I think including some sort of timestamp in the id would likely solve
> the problem of future conflicts. I don't think adding the actual date
> into the ID string would be that useful (how often would you be
> comparing dates from the ID property?), but the human-readable string
> could have a hash of the string plus (current-time) appended to it. Or,
> perhaps better, a hash of the outline path plus current-time.
>
> E
>
>
>

[-- Attachment #2: Type: text/html, Size: 4400 bytes --]

Re: Properties ID vs. CUSTOM_ID

[Carsten Dominik]

[-- Attachment #1: Type: text/plain, Size: 3661 bytes --]

And one more remark.

A main reason for the CUSTOM_ID (and my only use of it, really) it to make
HTML targets stable and meaningful.  In the following file


* aaaa
* bbbb
  :PROPERTIES:
  :CUSTOM_ID: Lotsofbshere
  :END:

you can have a stable link

to file.html#Lotsofbshere

Carsten

On Thu, Dec 22, 2016 at 10:31 PM, Carsten Dominik <dominik@uva.nl> wrote:

> Dear all,
>
> before continuing this discussion, and before reinventing, you might want
> to take a look at how org-id.el currently does create unique IDs.  In
> particular, take a look at these variables:
>
> org-id-prefix
> org-id-method
> org-id-include-domain
>
> In particular, the docstring of the variable org-id-method is
>
>   "The method that should be used to create new IDs.
>
> An ID will consist of the optional prefix specified in `org-id-prefix',
> and a unique part created by the method this variable specifies.
>
> Allowed values are:
>
> org        Org's own internal method, using an encoding of the current
> time to
>            microsecond accuracy, and optionally the current domain of the
>            computer.  See the variable `org-id-include-domain'.
>
> uuid       Create random (version 4) UUIDs.  If the program defined in
>            `org-id-uuid-program' is available it is used to create the ID.
>            Otherwise an internal functions is used."
>
>
>
> Hope this helps.
>
> Carsten
>
>
> On Thu, Dec 22, 2016 at 10:02 PM, Eric Abrahamsen <eric@ericabrahamsen.net
> > wrote:
>
>> Christophe Schockaert <R3vLibre@citadels.eu> writes:
>>
>> > Eric Abrahamsen writes:
>> >
>> >> Karl Voit <devnull@Karl-Voit.at> writes:
>> >>
>> >>> I'd prefer using manually written :ID: instead since migration would
>> >>> not be trivial to me.
>> >>
>> >> You could also use the `org-property-set-functions-alist' trick with
>> the
>> >> :ID: property. If you added an "ID" entry to that alist, Org's usual
>> >> automatic id creation would be unaffected, but if you set ID manually,
>> >> you could write a function that would first prompt for your
>> >> human-readable string, then check for ID uniqueness and append random
>> >> characters to your string until it was unique. I think that would be a
>> >> nice addition to org-id.el.
>> >>
>> >> Eric
>> > I thikn the tricky part would be that we can only ensure ID uniqueness
>> > for the current agenda at the time of the ID creation. What if we later
>> > merge another set of files where ID were created independantly to our
>> > acustomed agenda files ?
>> >
>> > I like the idea of assigning a date since we would reduce chances to
>> > define at the same time the same string and the same day. If meticulous,
>> > we could assign a date and a time or random string as you suggest, Eric
>> > (a tiny UUID :).
>> >
>> > I think I read somewhere the first inactive timestamp could be used to
>> > tag an entry with a date. At least, I do that frequently.
>> >
>> > Thus, if available, we could even use it as a date when creating the ID
>> > in order to have an indication of the creation time for the heading
>> > instead of creation time of the link.
>> >
>> > Here it is for my suggestions.
>> >
>> > Dates might not be appropriate for every situation, though...
>>
>> I think including some sort of timestamp in the id would likely solve
>> the problem of future conflicts. I don't think adding the actual date
>> into the ID string would be that useful (how often would you be
>> comparing dates from the ID property?), but the human-readable string
>> could have a hash of the string plus (current-time) appended to it. Or,
>> perhaps better, a hash of the outline path plus current-time.
>>
>> E
>>
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 5427 bytes --]

Re: Properties ID vs. CUSTOM_ID

[Eric Abrahamsen]

Carsten Dominik <dominik@uva.nl> writes:

> Dear all,
>
> before continuing this discussion, and before reinventing, you might
> want to take a look at how org-id.el currently does create unique IDs.
>  In particular, take a look at these variables:
>
> org-id-prefix
> org-id-method
> org-id-include-domain
>
> In particular, the docstring of the variable org-id-method is
>
>   "The method that should be used to create new IDs.
>
> An ID will consist of the optional prefix specified in
> `org-id-prefix',
> and a unique part created by the method this variable specifies.
>
> Allowed values are:
>
> org        Org's own internal method, using an encoding of the current
> time to
>            microsecond accuracy, and optionally the current domain of
> the
>            computer.  See the variable `org-id-include-domain'.
>
> uuid       Create random (version 4) UUIDs.  If the program defined in
>            `org-id-uuid-program' is available it is used to create the
> ID.
>            Otherwise an internal functions is used."
>
> Hope this helps.

Right, and we're not trying to reinvent any wheels, just get a
user-readable string in there while still retaining uniqueness. Ie, it
would probably be enough if org-id-prefix could be set to 'entry, and
org then generated a prefix by munging the entry text:

* My Great Header
  :PROPERITIES:
  :ID: my-great-header-44d1-b804-d11657131237
  :END:

Re: Properties ID vs. CUSTOM_ID

[Christophe Schockaert]

Eric Abrahamsen writes:

> Carsten Dominik <dominik@uva.nl> writes:
>
>> Dear all,
>>
>> before continuing this discussion, and before reinventing, you might
>> want to take a look at how org-id.el currently does create unique IDs.
>> [...]
>> Hope this helps.
>
> Right, and we're not trying to reinvent any wheels, just get a
> user-readable string in there while still retaining uniqueness. Ie, it
> would probably be enough if org-id-prefix could be set to 'entry, and
> org then generated a prefix by munging the entry text:
>
> * My Great Header
>   :PROPERITIES:
>   :ID: my-great-header-44d1-b804-d11657131237
>   :END:
Sounds good to me.


I still like the idea to be able to use a plain date, but when I need
it, I would most than probably set it as an inactive timestamp in the
entry title in my case. It would thus be addressed if the "munging"
would also handle cleverly the timestamp in an entry title (which it
should do anyway I think).

So, from my perspective, this approach fully fulfill the needs in an
efficient way.


Christophe

-- 
--------------->  mailto:R3vLibre@citadels.eu
Once it's perfectly aimed, the flying arrow goes straight to its target.
Thus, don't worry when things go right.
There will be enough time to worry about if they go wrong.
Then, it's time to fire a new arrow towards another direction.
Don't sink.  Adapt yourself !  The archer has to shoot accurately and quickly.
[Words of Erenthar, the bowman ranger] <---------------<<<<

Re: Properties ID vs. CUSTOM_ID

[Samuel Wales]

On 12/22/16, Karl Voit <devnull@karl-voit.at> wrote:
> However, the argument was that no human should set :ID: but use
> :CUSTOM_ID: *instead*. See also the old thread I linked before.

i don't recall anybody arguing, claiming, or implying specifically that.

if you're careful, and do not need custom id features, then you're
probably ok ignoring custom id.  sounds like you want reassurance that
you're ok?

Re: Properties ID vs. CUSTOM_ID

[Samuel Wales]

an example of a custom id feature might be for export.  sounds like
you might not need it.

org-depend improvements: TRIGGER in Combination With Set SCHEDULED

[Karl Voit]

* Karl Voit <devnull@Karl-Voit.at> wrote:
> * Carsten Dominik <dominik@uva.nl> wrote:
>
>> Since ord-depend was only proof of concept, we could also think a bit more
>> broadly about what it should be able to do.  Is there specific
>> functionality it also should support, besides the TRIGGER/BLOCKER functions
>> it has right now?
>
> Oh my goodness - free wishes for org-depend? Christmas is rather
> early this year! ;-)
>
> For reference purposes: http://orgmode.org/worg/org-contrib/org-depend.html

I thought about some org-depend improvements to take it to the next
level.

Since many Org-mode users do not know or use org-depend.el, I
decided to write a blog post about it and how improvements can easy
my digital life:

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

Some improvements are probably solved with a few lines of Elisp code.
Unfortunately, I am very bad at coding Elisp myself and thus can't
extend Emacs the way I would love to.

For discussion purposes, I now append the improvements as separate
mailinglist emails here as well:


4 Improvement: TRIGGER in Combination With Set SCHEDULED
========================================================

  I love the `:TRIGGER:' property because I can mark headings as open
  tasks only if they can be done now. Only headings which are ready to
  be looked at do have the `TODO' keyword.

  One limitation of `org-depend.el' is that I am only to move forward
  scheduled dates to siblings and I am not able to define a different
  scheduled date.

  Assume following syntax:

  ,----
  | ** TODO Asking the client about the project
  | :PROPERTIES:
  | :TRIGGER: 2016-12-18-send-offer(TODO,2016-12-23)
  | :END:
  |
  | ** Send offer to client
  | :PROPERTIES:
  | :ID: 2016-12-18-send-offer
  | :END:
  `----

  I extended the option of the trigger property so that I added an ISO
  date to the keyword parameter.

  What I'd expect is that on finishing the first task, the heading with
  the ID `2016-12-18-send-offer' not only gets the keyword `TODO' but
  also is scheduled for 2016-12-23 as well.

  Notice that the send-offer heading is not necessarily located in the
  same sub-hierarchy as the ask-client heading. Therefore,
  sibling-operations are not the whole answer here.

  Additional to this, I'd like to have the possibility to define
  relative schedule dates as stated in [manual for the date prompt]:

   `2016-12-18-send-offer(TODO,.)'      the day when marking the asking-task as done
   `2016-12-18-send-offer(TODO,+3d)'    3 days after the scheduled date of the asking-task
   `2016-12-18-send-offer(TODO,.+3d)'   3 days from the day when marking the asking-task as done
   `2016-12-18-send-offer(TODO,mon)'    nearest Monday from the day when marking the asking-task as done
   `2016-12-18-send-offer(TODO,+2tue)'  second Tuesday from the day when marking the asking-task as done


[manual for the date prompt]
http://orgmode.org/manual/The-date_002ftime-prompt.html#The-date_002ftime-prompt

-- 
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
       > get Memacs from https://github.com/novoid/Memacs <

https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github

org-depend improvements: Canceled Tasks Do Cancel Their Dependencies as Well

[Karl Voit]

* Karl Voit <devnull@Karl-Voit.at> wrote:
> * Carsten Dominik <dominik@uva.nl> wrote:
>
>> Since ord-depend was only proof of concept, we could also think a bit more
>> broadly about what it should be able to do.  Is there specific
>> functionality it also should support, besides the TRIGGER/BLOCKER functions
>> it has right now?
>
> Oh my goodness - free wishes for org-depend? Christmas is rather
> early this year! ;-)
>
> For reference purposes: http://orgmode.org/worg/org-contrib/org-depend.html

I thought about some org-depend improvements to take it to the next
level.

Since many Org-mode users do not know or use org-depend.el, I
decided to write a blog post about it and how improvements can easy
my digital life:

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

Some improvements are probably solved with a few lines of Elisp code.
Unfortunately, I am very bad at coding Elisp myself and thus can't
extend Emacs the way I would love to.

For discussion purposes, I now append the improvements as separate
mailinglist emails here as well:


5 Improvement: Canceled Tasks Do Cancel Their Dependencies as Well
==================================================================

  Wouldn't it be nice to have a general setting (or a property?) whether
  or not I want to handle canceled tasks differently as tasks marked as
  done?

  Imagine the example from above. Does it really make sense to send an
  offer when I canceled the ask-client task? Many people probably would
  love to cancel all follow-up workflow tasks as well.


-- 
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
       > get Memacs from https://github.com/novoid/Memacs <

https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github

Re: org-depend: dependencies between TODO entries in different files

[Samuel Wales]

On 12/12/16, Carsten Dominik <dominik@uva.nl> wrote:
> broadly about what it should be able to do.  Is there specific
> functionality it also should support, besides the TRIGGER/BLOCKER functions
> it has right now?

it can make a remote task get scheduled upon doneifying current task?

Re: org-depend: dependencies between TODO entries in different files

[Karl Voit]

* Samuel Wales <samologist@gmail.com> wrote:
> On 12/12/16, Carsten Dominik <dominik@uva.nl> wrote:
>> broadly about what it should be able to do.  Is there specific
>> functionality it also should support, besides the TRIGGER/BLOCKER functions
>> it has right now?
>
> it can make a remote task get scheduled upon doneifying current task?

When I understand
http://orgmode.org/worg/org-contrib/org-depend.html
correctly, this is only possible via chain-siblings-scheduled and
this is not that easy for arbitrary tasks using an ID-property.

I mentioned this as a nice-to-have feature in my previous email.

-- 
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
       > get Memacs from https://github.com/novoid/Memacs <

https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github

Re: org-depend: dependencies between TODO entries in different files

[Samuel Wales]

lovely that we are thinking of new stuff for org-depend.

On 12/12/16, Karl Voit <devnull@karl-voit.at> wrote:
>> it can make a remote task get scheduled upon doneifying current task?

for me this would be the killer feature.

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com

The disease DOES progress.  MANY people have died from it.  And
ANYBODY can get it.

Denmark: free Karina Hansen NOW.
  UPDATE 2016-10: home, but not fully free