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.
Daniel -