This dynamic block will list all items (including their priority) that link to
the item at point or to any of its parent items. The use case for this is to
have a series of periodic appointments where certain topics should be
discussed (“jour fixe”), and where those topics can be referenced in those
appointments via backlinks. However, simple backlinks to an item on a fixed
date is not sufficient here, as there might not be enough time on that day to
discuss all items. To avoid having to manipulate all backlinks that could not
be discussed, one could simply add a reference to the parent item of all
appointments of the jour fixe series. Using the new dynamic block introduced
here, this item will be on the list of open topics until it's closed.
Somehow, using lispy in the minibuffer causes random indentations although
everythin is on the same line. This might not be an issue with lispy itself,
disabling it however makes the symptom go away. Since I am not using lispy
features in the minibuffer anyway, I can as well switch it off.
There's a new mode map `eshell-hist-mode-map` which already contains a binding
for `M-r`, so we have to redefine that key binding there to make it work.
This allows to keep ideas for later in dedicated NOTE items, to group them
together. Not sure whether this is really a good idea, as it spreads those
ideas around, but let's try it out!
When inserting links multiple times, it's annoying to have to go back to the
original place the link points to and reinsert it into the stored link list.
Using a universal argument to toggle `org-link-keep-stored-after-insertion` is
also not an option, as I keep forgetting to use it.
Instead, by default keep all links after insertion. To be able to handle the
growing list of links, we now provide a function `db/org-clear-stored-links` to
set the list of stored links to the empty list.
We want `org-ql-search`, but need to install `org-ql`, so it's best to simply state
this in the `:ensure` declaration.
The `:commands` specification might be redundant, as `org-ql` comes with an
autoload file. But let's keep it there for clarify purposes.
This includes, among others, a dynamic block to insert the result of a query –
which is exactly what I am looking for. I have to learn a new query language,
though, but it seems as if non-sexp syntax is easy enough; and having a
lisp-like query syntax is undoubtedly a big improvement!
This way, the WIP list faithfully shows all WIP items and gives a better
overview of the current work load. Items will appear twice though when they are
scheduled today or in the past.
This should allow to have TODO subtasks in templates without them appearing in
agenda views, among others.
Tried to update some agenda views, but some configurations may still be missing.
When things are scheduled, they are shown in the time grid portion of the
agenda. When they are scheduled in the future, they will not show up until that
date is due; when they are scheduled in the past or present, they are shown on
the time grid directly. Both situations are sufficient, and it's thus not
necessary to show scheduled items in other lists as well.
Started dates are also WIP, in particular if they have been interrupted. Items
scheduled in the future should only appear on the WIP list when they are due.
I regularly filter the main agenda view for the CONT tag to see my WIP items, so
it's propably meaningful to have this as extra list. It's using some space in
the agenda view, though, so let's see how this will turn out.
This had been used to synchronize my calender with others, but since this
synchronization is not in use anymore, regular exports are unnecessary.
Furthermore, the export makes Emacs unresponsive sometimes, as the export does
not seem to be easily preemtable.
Enabling this somehow caused performance issues in Org Mode buffers, and since I
am not using this syntax, let's just disable it. This setting can be
overwritten via the Customize interface.
This allows to postpone projects into the future when they are not relevant now
but would otherwise be stuck. Because of the scheduling, an automatic reminder
will appear on the agenda when the date is due, upon which the projects is shown
again as stuck. Then new items can be planned, or other measure might be taken.
This should make the main agenda view into a good overview of everything that
can be done right now, allowing it to choose the next task directly from that
list. The scheduled items then are only meant for information and hiding future
tasks.
I had ≈9500 entries and I think this had been too much, causing noticable lag
when closing Groupd. In particular my email volume is much lower than this.
This is primarily to be used in the weekly review to check all next items for
still being relevant, but can of course be used for other purposes as well.
Apparently, this causes a considerable lag when drawing buffers (determined by
experimentation). It's not clear to me whether really moody is the cause of
this issue here, or some subtle side effect.
Those things are added at the end of the LOGBOOK, instead of at the beginning.
This does not help, I would rather like to have those things being added as if I
would have taken a note on the currently clocked-in task. Indeed, this is what
I have been doing instead of using those capture template, which is why this
commit removes them.
The reason to keep this off was that my solarized-theme did not have support for
this. Since I have hacked this support together on my own now, I can (and
should) also use it!
Enabling hl-line-mode globally causes undesired and disruptive highlighting
effects in buffers such as eshell. Enabling it in prog-mode and text-mode
should be fine, though.
Additional modes may be added later.
I do not use the completion provided by company-mode, and sometimes it's even
disruptive during writing. So let's disable it for the time being.
The original reason to keep it activated has been to have completion when
inserting links to local files. This can better be achieved by providing a
universal argument to `org-insert-link`.
This will move lines more to the left when specifying arguments to constructors
or functions on multiple lines. Nested function calls can also be broken into
multiple lines to reduce their overall line width. This looks nicer from my
point of view :)
From my point of view, it does not make much sense anymore to distinguish these
two lists. Reading items should be on the main next action list as regular TODO
items. Indeed, using dedicated READ state does not make much sense either, so
let's remove that one from our capture templates, too, but keep the READ tag for
now. However, we cannot remove it from the keyword list for now as we are still
using it in some old items.
When keeping old links around, it may happen that adding another link is already
present in `org-stored-links`. In that case, only a message is displayed (“This
link already exists”), but the link itself is not pushed to the front of the
link history. A subsequent insertion of the link then requires manual selection
of the desired target, resulting in massive interruptions of the current flow.
This is the current default value from Org mode. It also makes more sense for
my workflows, as those searches usually are meant to be worked upon, and
sorting by priority helps to find the most relevant items on those lists.
Topics are reviewed regularly (e.g, every month), so having a readily available
agenda view helps here. It's also easier, I think, to keep an overview over all
active topics if they are easily accessible in a custom agenda view.
Things to refile should not be shown on the main agenda, as this view is only
meant to show open tasks. Indeed, if to-be-refiled items are already done, they
should not be here for exactly that reason; and if they are not done yet, then
they will show up in the Next Action list anyway.
Bringing items to their (supposedly) correct location is not part of doing the
item, it's part of cleaning up (e.g., while doing the weekly review).
Emptying the refile file should still be done regularly, though, i.e., every
day (via a daily review) or weekly (in the weekly review).
Those files are specific for each machine where Emacs is running and change
often, and should not be included as private configuration files. Indeed, those
files might be versioned (e.g., using git) and deploying those versioned
configuration files over multiple machines would cause a number of conflicts if
Gnus' local mail files would be included as well (as has happend to me). Since
those machine-specific files are not really relevant for other machines, keeping
them somewhere else is reasonable. The new default is $HOME/.config/gnus-news.
Note that the main gnus-newsrc file is still kept as private configuration file.
Those tags are meant to mark the current headline (and nothing below) as either
just a headline (via NOP, i.e., no projects) or as a topic (i.e., a general
obligation and not a concrete thing to achieve).
This tells `org-set-tags-command` to not clear the NOP tag if it's available
somewhere at a parent node – a thing `org-set-tags-command` apparently seems to
be doing in general to keep the tags hierarchy clean.
To mark whole projects as SOMEWHEN may further declutter the main project list.
To not loose sight of those SOMEWHEN projects, however, they are not explicitly
shown in the SOMEWHEN list.
The SCHEDULED entry for projects (not for their respective tasks) is now used to
move currently irrelevant projects out of sight, and schedule them for later
resubmission. Indeed, those projects will reappear on the main project list
when the SCHEDULED date is due.
plantuml-mode derives from prog-mode, which in my coniguration automatically
activates subword-mode. However, as plantuml uses barewords as strings, those
are rarely meant to be in camel-case (indeed, typos are much more common) and
subword-mode is more distracting than helpful.
In general, all tasks of the previous week should still be present in this week
and the week before, so there's no need to activate archive mode by default. If
it's necessary after all, it can be activated manually.
This only means to wrap a `use-package` around the variable settings, but since
I may be playing around with this in the future, it's better to visually group
this configuration already now.
It's easier for the weekly review to see only those items that were closed, as
those may still have pending actions that need to be captured. Items not yet
closed are still available on the calendar, on the Next Action list, or
elsewhere.
We only ignored future items so far, but those that are scheduled today or in
the past are also in our focus (i.e., our the daily agenda). So let's not show
those as well.
This is the same sorting as it is used in the Next Action list, and should
provide a better overview over the current items on the Waiting-For list.
Formatted the value for `org-agenda-sorting-strategy` on one line for better
readability, and also changed that for the definition of the Next Action list.
The Read capture template did not properly ask for the topic and did not have a
placement indicator for the cursor, fixed that. The Response capture template
now has a “Reply ” action word to indicate the proper action, and also has a
placement indicator in it. This way, it should be easier to use these capture
templates.
As with the next action list, it's better to keep the reading list in sight so
that when I decide what to do next, it's there and showing me all the
possibilities.
At work, I am using the category to record the cost centers of the corresponding
actions. Maybe sorting the next action list gives a better understanding of the
overall set of actions by clustering them by category?
I somehow have the feeling that my next action list is not “present” enough and
so I am afraid to miss things. As an experiments, let's try to display the next
action list in the main agenda view to always have it in sight.
In that case, I sometimes want to add extra information, like scheduling a
date or adding extra references. This is not easily possible when the capture
is closed immediately.
Using the buffer name does not seem to play well together with org refile
keeping the last choice on top of the candidate list, because a slash is
automatically appended to this entry. This results in an invalid refile
location. Thus reverting back to only using the file name, it's fine this way.
Those will be done somewhen, if at all, and are not necessarily associated with
any action. So let's keep them off the reading list consisting of read actions.
The next actions list now also contains that have a deadline, but are not being
scheduled. This is more in accordance with the GTD method, as items with a far
deadline can still be done today, and for this they have to appear in that list.
This might be used before loading pyvenv, so let's include it in the autoload
list.
However, it seems pyvenv is loading its autoloads anyway, so this change might
be irrelevant. It's still nice to have it here for documentation.
When running this Emacs configuration on different hosts (with different
operating systems …), virtual environments for Python may be available in
different locations. So we allow the environment in which Emacs is started in
to overwrite the value of WORKON_HOME to accomodate for this.
Buffers are made globally unique, while filename usually are not, like my
various project diaries. This new setting allows to distinguish targets in
equally named org mode files directly when refiling (and thus also when
inserting links).
As for eshell, path completion in shell mode erroneously adds extra spaces when
using ivy. Since the builtin completion is good enough for shell mode anyway,
let's stick to that. No bad surprises.
eshell is using pcomplete as completion meta-framework, which by default will
insert the value of `pcomplete-termination-string` to each finished completion.
However, when using newer versions of `ivy` for path completion, each completed
directory within a path is considered a finished match, and pcomplete will
insert a blank. This is annoying, and since we do not require the final blank
otherwise, we can equally just disable it.
When only signing with S/MIME, `message-encode-message-body` complained about
not being able to find \n\n. However, we only need the conversion when
encrypting with S/MIME, and apparently the LF → CRLF conversion hack is working
in that case.
However, I think there should be some way to fix this properly within Gnus,
maybe via some configuration … I think I have to write to the Gnus Usenet group
for this.
This causes lagging while highlighting symbols, and the highlighting itself does
not add much value. Disabling it thus does not hurt and gets rid of the
lagging.
This is mostly because I haven't had time to understand what the `:custom`
keyword is actually doing. Apparently, it introduces customizations without
user interaction, which in turn makes changing default values a manual
process (by changing customizations one has never done) thus resulting in
inconsistent behavior.
As per the documentation (see "(elisp)Startup Summary"), only variable
customization that affect package initialization should go into the early init
file. Defining package archives is explicitly mentioned as something that still
may go into the main init file. So we move it there and adjust comments
accordingly.
This avoids headline-references (as opposed to referencing IDs) when implicitly
creating links in new items through `org-capture` when already in `org-capture`.
In that case, the %a template specifier will call `org-store-link`
non-interactively (as it seems) and the old setting of
`org-id-link-to-org-use-id` created links based to the headline of the target
instead of creating a new ID property.
Note that this will also always ignore CUSTOM_ID properties, but I haven't used
it anyway.
Keep the standards as they are and customize the variables when necessary.
Changing the defaults almost always causes trouble when running on other
machines. For example, `python3` is the name of the Linux executable, but not
the Windows one.
Inspired by [zamansky](https://cestlaz.github.io/post/using-emacs-74-eglot/).
There were some problems with the builtin version of `project`, I had to delete
the `elpa-ess` Debian package, because it was pulling in the builtin version of
`project` before `package.el` could set up the proper paths. I need to
investigate how to avoid this behavior in general.
The generic definition for the "todo" state-change must have overwritten the
other, more specific definitions for the other TODO-type states. Fixed this by
removing the generic definition.
Also added some more tag triggers as well.
This only unnecessarily clutters the use customizations. If proxies are
important, configure them explicitly, which is easy; if they are not important,
they don't have to be saved.
Using sshx as default on non-Windows systems seems to be a more robust choice
than using ssh, because the latter might be prone to errors caused by my
user-specific shell configuration. And while we are at it, using plink on
Windows is more reasonable than using ssh, at least in my working environment.
Indeed, in my workflow, the effort estimate of an item is independent of the
effort estimates of all its subitems. It thus does not makes to sum them up,
and indeed the "{:}" in the column view format causes the (independent) effort
estimate to be overwritten by the sum of the efforts of its subitems every time
column view is turned on.
From our previous attempts to get S/MIME working when using Outlook, the
function `mm-copy-to-buffer` had been adviced to change all LF to CRLF, to allow
`mm-copy-to-buffer` to find the beginning of the body. However, when the body
itself is binary and accidentally contains an CRLF, that content is modified as
well. This might break the content, as it happend with the signature of
elpa.gnu.org, which indeed contained an CRLF.
We are now a bit more non-invasive and replace the original version of
`mm-copy-to-buffer` with one that explicitly also searches for ^\r\n in addition
to just ^\n. Let's see how good that will work. Signature checking for
elpa.gnu.org is functioning again, and S/MIME still seems to be working.
This allows easier updates of this list, without having resort to executing the
corresponding code manually. In the future, we could even update that list
automatically by attaching the new function to some of projectile's hooks or
something.
The main motivation is me often mistyping S-SPC for SPC, loosing my current
candidates and frustrating myself. This is even more frustrating when inserting
text into non-selection inputs (org-capture), which is why we had disabled ivy
completion for org-capture previously. Since we are no using
ivy--regex-ignore-order for candidate regex building anyway, input restriction
is not necessary anymore, and so we remove the shortcut altogether.
This reverts commit 2622b048b6.
The main annoyance has been completion in org source blocks, and this has been
disabled now. Additionally, `company-complete` only seems to work when
company-mode is enabled. So let's enable it again and see how far we get.
When company is active, this leads to completions offered as a first step in
shell blocks, for example, which is both unnecessary and triggers a bug in
ivy (the cursor is invisible afterwards). Furthermore, this completion is
almost always unnecessary, as the snippets a usually either quite simple or
copied from elsewhere. If completion is still required, editing the code block
within the native major mode (C-c ') should be sufficient.
Most of the time, I just want to see the text and edit it, and thus I open HTML
files in Emacs anyway (usually rendering them via `shr-render-buffer`).
It's confusing me that the output of pandoc is a document fragment by default,
so let's instruct Emacs to generated complete, standalone documents instead.
Apparantly, when Gnus starts up for the first time, this function seems to be
undefined, because we are calling gnus-registry-initialize quite late in the
init process. Let's try to fix this by having this autoload.
Outlook seems to expect CRLF in S/MIME signed+encrypted mails, so we add those
somewhere in the process of encoding the mail. Furthermore, Outlook is sending
MIME messages with CRLF line endings, and we have to take care of that when
looking for the end headers.
The changes proposed here are preliminary and subject to further testing.
Let's group configuration related to MIME decoding and MIME encoding, to better
understand what these variables are actually doing and to decrease maintanence
complexity.
Scoring didn't work in my IMAP mailing list folders, but not it should. In all
other folders, as long as there is no scoring file, nothing should happen.
Flycheck used to be activated unconditionally, resulting in annoying warnings
when evaluating Lisp expressions in the minibuffer with `pp-eval-expression`,
and in the scratch buffer.
It used to be slow, but it's not the case anymore. This should help identifying
problems in my ELisp code, but might cause some trouble on Windows. Let's see …
This one works with emms 6.0 and later, even when including
`helm-source-emms-streams'. Thus, we also use the default value of
`helm-emms-default-sources' again.
This makes eshell completion use drop down menues instead of the standard
complete-until-ambiguous style I am used to. Moreover, in Org Babel shell
source blocks, ivy completion in region causes a drop down menu of possible
commands to appear after a block has been created and entered for the first
time, which not only is annoying, but also sometimes causes to cursor to
disappear (set `cursor-type' to 'bar to revert).
It's rather annoying, from my point of view. The original use case was to
complete file names in links, and this can be done by calling `company-complete'
explicitly.
The builtin default of 128 is too low, resulting in recently used commands to be
forgotten quickly, so let's use a more conservative (in the literal sense of the
word) value. Customization still takes precendence over this new default,
though.
Apparently, with the advent of Emacs 27.1, Gnus clears up everything before
startup. Sadly, this also removes any initialized registry, such that we are
left with an uninitialized registry on startup. To remedy this, let's postpone
the registry setup right after Gnus has started.
There are often small tasks that do not require the former minimum of
15 minutes, resulting in effort estimations that are too high. Conversely,
larger tasks are often hard to estimate correctly, which is why the higher
numbers are now further apart.
F9 is a comparably prominent key binding, and we now bind it to the more
important `db/org-add-link-to-other-item'. The formar binding to
`db/org-find-links-to-current-item' is bound to F11 now, since it will still be
used often, but not more often then inserting links (I think). The old binding
for F11 to `org-capture' has not been used much, and so we can dispense of it.
The main entry point is now `db/org-find-links-to-current-item', which decides
how to obtain the ID and CUSTOM_ID of the item to look for. The main work is
done by `db/org-find-items-linking-to-id', which does some checks, build the
query, and then calls `org-search-view' (which, indeed, does the actual work).
Users should call `db/org-find-links-to-current-item' only.
It is not clear what function really changes the matching data, but it's called
by `org-roam--id-link-face', and this is where we save the matching data now.
TODO: check whether this has been reported or even fixed upstream.
Well, there wasn't any configuration for it right now, but the use-package
statement was hidden in the config section of dired's. Moved it to the
top-level right now and also bound dired-subtree-cycle.
This is for when dired+ is not available (which is current the case, because
dired+ does not seem to be available from melpa and the previously used version
was too old).
This should allow to distinguish proper tasks (“projects” in the PARA parlance)
from areas of responsibility. It currently mimics the semantics of the NOP tag,
but may be updated later on.
The present configuration is supposed to start the server if it's not already
running. Previously we checked this using `server-running-p', but this is not
really realiable. Instead, we now checking the `server-process' variable
directly.
Furthermore, if it turns out during startup that the currently configured server
file is already present, we warn the user about this and don't do anything
else. We let the user to fix it manually because it's (i) easy for the
user (easier than doing it automatically) and (ii) only done once, namly during
startup (the burden on the user is thus tenable).
The current implementation may not be accurate, though, as my understanding of
the implementation around Emacs' server functionality is only at the beginning.
This is some relic from former configurations, and might have been wrong quite
some time now. However, in Emacs 27+, package initialization is done before
loading user-init-file, and thus we don't have to do it by hand. Before that,
package initialization was done after reading user-init-file, but before calling
after-init-hook, and since we needed to load some packages in the init file, we
had to initialize package.el ourselves.
The shortcut in the frequently-used menu now points there, and not anymore to
the dedicated home and work files. If only a single main Org Mode file is used,
this variable should be sufficient.
Configuring custom key bindings via use-package's :map keyword does seem to
install autoloads for the bound functions into the main helm package. I.e.,
when binding `db/play-radio-stations' to # in `helm-command-map' via :map,
use-package seems to install an autoload for `db/play-radio-stations' that
requires `helm', instead of the correct `db-music' package. Additionally,
defining key bindings somewhere in the init file is hard to manage, and they are
thus now collected with other key bindings in `db/run-init'.
`helm-mode' should actually not be activated, since we are still using ivy for
`completing-read' and friends. That being said, when we want to enable
`helm-mode' in the future, we should also not call `ivy-mode' anymore.
Autoloading helm does not work well with custom keybindings. Binding our
default "C-c h" to either `helm-command-map' or `helm-command-prefix' gives
errors, as both are not commands. In the previous configuration, the prefix
"C-c h" was initially undefined and only defined when helm was loaded. This led
to irritating behavior.
All this can be fixed by eagerly loading helm. This may slow down startup, in
particular on Windows, but it should be worth it.
It was actually only used for playing EMMS streams, but since the implementation
has been rewritten in EMMS, helm-emms does not work anymore. Replaced the radio
playing functionality by a custom function, obsoleting helm-emms.
That's not only good enough, but also much more predictable than using the
currently used shell. Customize `explicit-shell-file-name' if you don't want
bash.
Turns out the reason was another version of `python-mode' being installed in
parallel. Removing that mode fixed the issue. Standard `python-mode' together
with elpy is sufficient for now.
Then a project is set on hold, the HOLD keyword is added. When reverting the
hold state, projects go back to not having a keyword. In this case, the HOLD
tag remains, because the old trigger definition was missing a case for the empty
keyword. This is now fixed.
In our configuration, projects are headlines without TODO keywords, that are
neither periodic tasks nor dates (dates usually have todo keywords, namely GOTO
or ATTN, but sometimes dates are just for information, and then the keyword is
missing). Additionally, projects are not tagged with NOP.
This listing helps to see the current projects one is working on.
This is possible because the state triggers are working correctly now.
Note: add the WAIT keyword to all existing waiting tasks, or otherwise this
the Unsupervised view will not work correctly!
When filtering for tags instead of todo keywords, inheritance kicks in and makes
handling tasks on hold much easier: the relevant headline can be set on hold,
and all subtasks are automatically on hold as well.
The agendas for monthly reviews and notes are gone, I don't use them. My
monthly review does not look at the agenda at all, only at my backlog.
Searching notes is done using Org's search functionality, and it's working very
fine.
The „Everything“ agenda has been renamed to „Unsupervised“. The name
„Everything“ is not apt anymore, as this view clusters items that are not
displayed in the main agenda or are stuck. The name „Unsupervised“ is a little
bit better, but may also change in the future.
Add a new view for listing all items that are not periodic and not part of the
personal backlog (i.e., not tagged with SOMEWHEN). This list should help
getting an overview over the current workload of real TODO tasks. Note that
both periodic tasks (tagged with PERIODIC, i.e., series of tasks) and regular
tasks (tagged with REGULAR, i.e., repeating tasks) are excluded from this list.
Descriptions of agenda views have been extended whereever it felt necessary.
The template for simple tasks should be simple, but got more complex in the last
change. This mistake is reverted with this commit, and the usual "t" can now be
used again for simple tasks. The "T" shortcut now provides capture templates
for complex tasks, but since complex tasks are both manifold and rarer, the
capture templates are provided with two-letter shortcuts.
The `db-music' package is supposed to be an abstract interface to music
functionality, and should thus define the main hydra for this. Moreover, the
hydra should not contain „emms“ in it's name, although it's using only EMMS
functions.
It's not clear whether EMMS will every be replaced by some other backend, but
it's nicer to have a (more or less) clear separation between user frontend and
implementation backend.
The idea of having a hydra to access frequently used features is certainly nice,
but quite hard to achive when one wants to redefine the hydra every time
`db/frequently-used-features' changes. Regrettably, there are not „ephemeral
hydras“ that are created every time one would like to access it. Therefore, the
shortcuts hydra is removed for now, but may come back again when we have found a
better way to handle its dynamic nature.
Org's capture template now distinguish between simple tasks, complex
tasks (i.e., those that need a separate headline because other subtasks may
follow later) and tickets (complex tasks that have a ticket number and a
reference). Those things are necessary for work and may be helpful also
elsewhere.
From time to time, a new item introduces a more complex task that requires a
separate headline. The new capture template is meant for this use case: it will
ask for a ticket number (the complex tasks I currently have to deal with always
come with a ticket number), a headline description, a reference (link to
redmine ticket or something), and a first task (usually a link to the first
email from the ticket). It might be that the template is too specific, but
let's try it out first and adapt it if necessary.
Every so often, I accidentally close Emacs by confusing C-x and C-c. To prevent
this, unbind the default key binding C-x C-c for closing Emacs. Instead, we can
directly call `save-buffers-kill-emacs', what is what I am usually doing.
And, seriously, why should anyone close Emacs in the first place?
If the only item below a task is a meeting that is currently attended, and thus
marked with the ATTN keyword, then the task as stuck. Indeed, during the
meeting, new items may be added to the task at hand, so that after the meeting
is finished, the task will still be not stuck. Because of this,
`org-stuck-projects' has been updated to not classify tasks as stuck if an item
with ATTN keyword is attached to it.
I don't like to store my passwords in plain in my files. Next step should be to
cache the password, but maybe this is already achieved by using a dedicated
session?
A periodic task is a task tagged with :PERIODIC:, and whose first child is an
item called "Template". Following the template are the instances of the
periodic tasks, which constitute the actual things to do and which can be
scheduled independently of each other. Whenever such an instance is due, the
template of the periodic task is supposed to be copied to the instance as a
first step. This copying can be done manually, but of course doing it
automatically is easier. The new function added in this commit represents a
first try to add such an automatism.
Often, I want to open some file and try to first open the corresponding buffer
in the hope there's some open buffer for it already. When no such buffer
exists, I have to close the list of buffers, reopen the helm shortcut menu, and
navigate to the corresponding bookmark. This is cumbersome and somehow
duplicate work, since the bookmark and the file most often are named similarly.
With a buffer overview in the helm shortcut menu I can now search for the file
directly and if it's already open, directly select the corresponding buffer.
If it has not been opened, though, I can navigate to the corresponding bookmark
with at most one additional keystroke (C-o) and open it there. Nice!
As described in [1], we are sometimes representing recurring tasks as lists of
single tasks plus a recurring task to create new instances once in a while. All
of this is grouped under a common headline, and those headlines should be marked
with PERIODIC to inhibit automatic clock-in.
[1]: https://karl-voit.at/2017/01/15/org-clone-subtree-with-time-shift/
RFC documents do not change over time. The custom org mode link handler
`db/org-rfc-open' now makes use of this by downloading RFC documents to
`db/rfc-cache-path' (if defined) and opening the files locally. If
`db/rfc-cache-path' is not defined, the RFC is opened in an external browser as
before.
This allows to keep a selection of used RFC documents locally on the filesystem
for future reference, without the need to retrieve them again from the IETF.
Since this is all org mode related, the handler now also resides in `db-org'
instead of `db-utils'.
Previously, a project was not stuck if any subtask was tagged NOP (no-project).
However, this led constellations like the following to be hidden from the stuck
project list:
* Test :NOP:
** TestTest
*** TestTestTest :NOP:
In this case, the NOP at TestTestTest would result in hiding TestTest, which,
however, does not have any more things to do and should thus be marked stuck.
The new configuration will check NOP only at the top headline, and not at any
other sub-headlines. For this, a property search TAGS={NOP} is necessary,
because otherwise tag inheritance would result in wrong false negatives.
It is no good to update `org-agenda-files' when setting those variables, only to
be overwritten by customize itself latter on. Maybe it's better to instead have
a custom setter that updates the variable, but also checks whether the file is
also contained in `org-agenda-files', warning the user if this is not the case?
Up to now, it seemed to be sufficient to set `send-mail-function' alone, but
somehow some changes have made it necessary to set `message-send-mail-function'
explicitly. If not done, it defaults to `message-send-mail-with-sendmail',
using the sendmail exectuable to send mail. At least on my machine this results
in the message being delivered to the local exim instance, which does not allow
sending remote sending of mail.
If this is necessary, clock in separately using the interruption template.
However, I have felt that this is rarely useful, to the extend that I haven't
used the note capture template just because it disturbs the clock.
