Hello, my name is Karl Voit
and I'm going to show you a little demo
on how I'm working with links
between arbitrary headings
and how I define dependencies between tasks
when I'm working with projects and so forth.
For that purpose, I've created a repository
that contains the files we are going to work with,
with the overall setup and so forth.
So you just have to download this repository
and you're able to replay everything
which you are going to see here.
If you've downloaded the configuration of the demo,
you see those files, and you start the Emacs
with an empty configuration
and link demo file, like that.
So let me just briefly increase the font size.
Setting up the demo is easy.
I've done the key visualization,
the webcam part, and I've started the Emacs
and increased the font size.
And the last thing and the most important thing
you need to do here
is executing the babel block,
which consists of more or less dirty Elisp code
that installs the necessary packages, functions,
and bindings required in this demo.
You need to acknowledge the execution
with yes and return, and after a couple of seconds,
everything is downloaded
and set up nicely for your demo.
The first demo is the demo
where I'm going to show you
how I'm working with links
between arbitrary headings.
It consists of two commands,
org-super-links-quick-insert-inline-link,
and the second one is
org-super-links-quick-insert-drawer-link.
So the difference is,
the first one is an inline link,
and the second one only depends
on the drawers of the headings.
So let's show you what I mean.
If I'm inserting here the inline link
to the second one, which I have to choose
from the result set here,
you see that there is this second heading link
included here in the first heading.
Let's open up the first and second heading.
You see that I can jump this link
to the second heading. The first heading
as well as the second heading
get human readable IDs,
which I personally prefer.
The second one gets
a backheading in a link drawer,
which was created automatically.
So this is a method where I link arbitrary headings,
and that's the main reason
why I personally don't need any
Zettelkasten-based method like Org Roam.
The next command which I want to show you
is the link between those drawers.
So in order to link the third to the fourth,
I need to look for the fourth.
In this case, you do not see
any inline link like here above,
but you see the :PROPERTIES: drawers
and the :LINKS: drawers in both headings.
So there is a forward- and a back-link
between those two headings,
and if you see a links drawer
you know that there are
linked headings you can follow.
I do find this method very very handy.
Of course, this doesn't only work
within one single Org mode file.
It works between arbitrary Org mode files
as long as they are
part of your Org Mode agenda list.
So that was the first heading
with the bi-directional links.
The second one is a little bit
more complicated than that
because I show you how I'm working with projects.
Usually, I start the project
by adding a "Why?" statement
so that I remember why this project
needs to be done in the first place.
I do a brainstorming on the tasks
that need to be done in the project
as a simple list.
With this handy command (C-c *),
I'm converting it to a list of Org mode headings.
Now let's add the NEXT keyword,
which is my default to-do keyword,
to the first heading.
You notice that there is a CREATED property
which is not relevant to the demo itself,
but it's part of my setup.
I really like those created headings
because when I add arbitrary headings,
this CREATED property is added automatically.
So now I want to define a dependency
between "Empty garage"
and "Paint walls and floor."
I do that by invoking my command here,
and look for the "Paint walls" heading.
In this dialogue, you may add a scheduled date
and/or a deadline date
and/or a to-do statement. For this demo
I only choose the to-do keyword.
You notice that there is
this TRIGGER property added.
That's default behavior of org-edna
which is managing the dependencies, in my case.
In the other one, there is this BLOCKER property.
It's very handy to know that those IDs
might be used for jumping
between those dependencies again.
Those two headings don't have to be necessarily
in the very same Org Mode file.
They may be scattered around
your Org Mode agenda files all over the place.
So continuing this definition of dependency
between the second and the third one...
I'm using the search "Bring back stuff"...
the search functionality...
I choose the NEXT keyword here, its dependency.
The same holds true for the last two.
"Is painted", for example. I'm going to use
the NEXT keyword again.
I tend to use the last task of any project
to close the overall project.
So if I show you this one,
I'm using the dependency to "Garage" project,
and this time I'm using the DONE keyword.
Of course, the properties
look like that all the time,
so there is a trigger from the first task
to the second one, and there is a blocker
from the second one back to the first one,
and when I'm actually doing the project,
I may now mark the first task as DONE,
and you notice that the second one
automatically gets a next keyword.
This happened, of course, for all those tasks.
The neat thing is when I close the last one,
the overall project gets its DONE keyword as well.
So this is how I'm working with
projects and dependencies.
Most of the time, task dependencies
are not even within the same Org Mode subheading,
let's say. Also, I'm using dependencies
between different Org Mode files.
This is a very, very cool way of defining
what to do next in a project,
without looking for tasks
that can't be done at that stage.
You can have a look at the details of the demo
by checking out the files in the repository.
That's it for the demo,
and therefore I thank you for your patience.
I wish you good luck,
and I hope that I could show you one or two tricks
that you can add to your Org Mode setup
in order to help you with your daily work.
So bye from me, till next time.