`td` will display things that are either due today or in the past, or
scheduled today or in the past.
`TD` will _only_ display things that are explicitly due today or in the
past.
Rename mail utility programs (yet again), to be prefixed with `mail-`
instead of `neomutt-`. Also did not substitute with other MUA like
`aerc-` since these utilities are mostly independent of specific
implementations.
The very specific `neomutt-filer` implementation script I completely
removed since for aerc the same can be achieved with a simple
configuration option.
Since we do not use neomutt anymore. Additionally, perhaps a 'mail-'
prefixed system is better for scripts etc which run independent of a
specific MUA.
Explanation here:
https://man.sr.ht/~rjarry/aerc/configurations/mailto.md
I built a custom script 'aerc-in-terminal' since I want to expand the
$TERMINAL env var and use that instead. `.desktop` files do not allow
expanding vars (since they don't run in a user shell), so this is a
compromise.
Mails get symbols in the flag column if they are sent by me, CC or BCC
me, or they are tagged as a 'list' (from a mailing list).
Added some additional info to status bar (current folder, recent and
unread counts), and extended the flag column slightly to accomodate more
flags.
Starting to replace neomutt in my workflow with aerc:
it is a little more lightweight, directly supports notmuch directories
and has a relatively sane configuration style (mostly just ini-like)
with 'go-templating' baked in.
In general, the configuration just feels less 'cobbled-together' than
before. I can make changes without worrying what other things are going
to break by doing so. I understand the complete configuration and
styling, instead of mostly relying on other people's formatting lines
for the styles.
I am still learning some of the configuration possibilities but it
already functions as a neomutt replacement.
Hitting `,m` in the compose menu creates a dual txt/html email group
when the highlighted file is written in (djot) markdown.
Delete the original message afterwards to create a fully functional html
email with plaintext fallback.
Completely taken from: https://tom.wemyss.net/posts/neomutt-markdown-email/
with many thanks. What an amazing use of pipelines in neomutt!
First we unbind all existing key mappings and then we slowly build up
our own again. May be somewhat unnecessary but I have been getting
_very_ confused with neomutt mappings just popping up all over the place
and never quite sure if they were from me or default settings or where
exactly they were configured.
This provides a clean slate to build upon.
In its default pre- and post-hooks, `neomutt-syncmail` now checks if
`imapfilter` and `notmuch` exist before invoking them.
Similarly, it defaults to `pass open` opening a pass coffin if
`pass-coffin` exists.
Renamed `mutt2task` to `neomutt-2task`, and renamed `sync-mail` to
`neomutt-syncmail`.
Changed key maps accordingly. Also systemd service even though I don't
think I'll use it again.
We have differentiated views of new (italic) and unread (underline, and
a bit of highlight on the author) messages.
Additionally the indicator highlighting works better with the rest of
the colors, and we have a better paperclip icon icon for attachments.
E-Mails have 2-staged flag options for levels of 'seen':
Unseen/Seen and Unread/Read.
A message is unseen if it has arrived since the last time we had mutt
open. We do not have to have had the actual message open for it to be
marked seen (or 'old'). In other words, whichever messages we have seen
once on the index alone are not 'new' to us anymore, they have been
seen.
On the other hand, a message is only read if it is actually opened. So
even if we have seen it on the index page, or moved it to a different
mailbox or anything else, it can still be unread if we did not open it.
Additionally, I have it set up now so that the message only gets set to
'read' by neomutt after it has been open for 1 second.
This gives a tiny grace period if we are scrubbing through mails or
accidentally opened one we did not want.
In 'next' view (my default) we list all annotations as normal with their
full text.
However, in 'list' view, we only show how many annotations are on a task
(if any) and do not display their contents. This turns it into actually
more of a list if there are many annotated tasks.
Following this blogpost:
https://eshapard.github.io/code/a-separate-taskwarrior-configuration-for-ideas.html
I think it is a really good idea to try this out.
At first I was collecting ideas in my regular taskwarrior repository --
this was no good as every task list was flooded by somedays and maybes
which would never leave. But I still wanted to have a nice repository to
collect all my ideas in.
So, the second strategy was to have one big (markdown) file which would
simply collect all my ideas. But now I was doubling and tripling them up
because the list was so long, and it was more of a chore to find where
to put everything than just a quick 'idea add'.
This may be the best of both worlds: making use of the nice interface to
a task database using the full strength of taskwarrior querying, without
cluttering up my main task repository.
The workflow is exactly as with regular taskwarrior, only the executable
is not called `task` (or `t` in my case) but `idea`. So you e.g. add an
idea with `idea add`, or query all diy ideas with `idea +diy`.
Just like regular taskwarrior.
Since I am exclusively using `topen`
(https://git.martyoeh.me/Marty/topen) for my task notes currently, this
commit gets rid of any left-over config files setting up `taskopen`.
Starts to simplify the taskwarrior setup a tiny bit.
Can show tasks accomplished today (tdd, 'Task Done toDay'), since
yesterday (tdy, 'Task Done since Yesterday'), or in the last week (tdw,
'Task Done in the Week').
Taskwarrior hooks are removed from this general dotfiles repo, as they
are instead included in my taskwarrior 'task' folder (and project)
itself. Each hook belongs to exactly one taskwarrior repository and thus
they should also exist there and not anywhere else, is my current
opinion.
This is especially so since I believe most people use exactly one
taskwarrior repository (me included). So for the moment it just makes
the most sense to have these two things live side-by-side instead of in
this more general configuration repository.
By default sort the exported output by creation date and modify date.
Also use the jq expanded (prettified) output. Will take a little more
space, but ultimately makes it easier to see task changes since each
value is on a single line.
In preparation for integrating bugwarrior into these dotfiles I am
changing the taskwarrior include options to absolute paths (though still
retaining the `~` home shortcut).
This seems necessary as bugwarrior, both in its current 1.8.0 and its
git HEAD version, just absolutely refuses to run when the includes are
relative to the taskrc file. A little sad but not too bad overall since
the taskrc in these dotfiles will always live in the XDG_CONFIG_HOME
directory anyway.
