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.
This commit changes the way I display my jj logs a little. We
distinguish between 3 styles now
- the 'stack()': short and to the point, only ancestor commits from the
last non-mutable one onwards
- the 'recent()': the previously default view over ancestor commits or
any other head nodes (i.e. any branches) that are from me,
with a few commits leading up to them visible.
- the 'all()': the traditional 'show everything' summation for finding
very specific commits or getting a macro-scale overview of the history
Basically, only the 'stack()' view was added - but it is now the new
default for the default command and the previous 'default' has been
renamed to 'recent()'.
This is mirrored in the shell aliases: all the `jl`, `jlo`, `jloo`
aliases use the 'recents()' view. The capital versions (`JL` and the
like) are not affected as as they keep showing the 'all()' view.
Importantly, the `j` base command uses the 'stack()' view, however.
Lastly, we extract the aliases to find `WIP:` commits and `PRIVATE:`
commits into actual jj revset aliases and call them from our shell
aliases. The functionality does not change, though we now have an
additional alias for finding specifically the latter commits with `jlfp`
('jj log find private').
Using lazy-events.nvim we can create custom events (such as the LazyVim
equivalent LazyFile event) based on other events (i.e. a grouping), on
globbing files in the current dir, or on arbitrary custom logic.
For now, any plugins which require files to be present to work are
loaded with the 'LazyFile' event.
Any plugins which need to be loaded when opening a directory with vim
are loaded with the 'StartWithDir' event (essentially only neo-tree for
now). Similarly mini.starter is loaded on the `StartScreen` event.
Any plugin which only makes sense to run in a `.git` dir (gitsigns etc)
will only run on the `LazyProject:git` event.
Automatically opens dap-view when in debugging session (and closes when
done), sets some breakpoint jump logic and makes the gutter symbols
nicer.
Adds keybinds for most of the dap operations with
`<localleader>d<something>` where something is the operation (i.e. `c`
for continue, `b` for breakpoint and so on).
For now there is no strict reason to have it disabled, even if I don't
use it much. At the same time I can always re-disable it if I need the
bracketed movement for something more important later down the line.
In preparation for adding debugging we change the bracket movement
between diagnostics from `[d`/`]d` to `[e`/`]e` instead.
This will be a big switch in muscle memory for me and I hope I can adapt
to it pretty quickly, but at least mnemonically it still makes sense
since we jump between [E]rrors (or warnings but good enough).
mini.bracketed never received its configuration which is the reason I
had some issues in the past. It was simply wrapped in one too many
layers of tables. Now works as intended.
Treesitter had to run as a non-versioned (trunk-tracking) plugin for a
while since there was no updated version released.
Now that it is we can return to a nicely versioned tag.
Sad but I'll have to face it - I've never successfully used
criticmarkup in, by now, 6 years of professional academic writing.
The plugin also does not work as well as it should (anymore?) with my
current neovim setup. The `:Critic` command works neither with accept
nor reject and the different highlights are presumably overwritten by
treesitter queries.
Now, all of those _could_ be fixed but as I say above, I have never
successfully used the markup. Perhaps one day it could be implemented in
a slick nvim lua plugin with hiding and extmarks which mimicks a truly
nice review editing experience. But not today.
Old versions of render-markdown.nvim suggested renaming it to another
plugin name, but this seems to not be the case anymore. I removed both
for the time being and it fixed a long-standing issue I had with the
plugin.
Whenever there is a left-over quote (') or double quote ("), if we want
to 'close' it, mini.pairs will by default add a new pair (e.g. """)
instead. This simply changes it to close the pair. Makes some
'double-quote' pairings harder (e.g. we have a python dict: {"name"})
and want to add another {"name""value"} into it, but this happens
relatively rarely in my use cases. The first on the other hand happens
frequently enough to be an annoyance.
Additionally, did the same for back-ticks so we can more easily create
triple backticks ``` which are essential in many literate programming
markup languages (markdown, quarto, rmd and so on).
Makes it easier to read lists, and also easier to work with
markdownlint even if it has not been configured for a given repository
(since its list indentations default to 2 spaces).
For some versions apparently markdown preview could not be built anymore
with the suggested installation in the readme. Instead it requires the
build function to be called through a string from lazy.
See:
https://github.com/iamcco/markdown-preview.nvim/issues/690
Remove deprecated 'ui.diff.format' setting and replace with
'ui.diff-formatter'.
Use the time to also ONLY set up delta as the diff and show command
pager using scopes (since I was perusing the jj discussions anyway).
This has the advantage that normal jj paging is done with `-FRX` as far
as I understand -- which means after we close out of the pager the
content remains on screen (-X). This is not the case with delta. So now,
the contents of e.g. the last log command should always stay on screen.
Shows if the pc will not automatically turn off screen or suspend.
Figures this out by checking for `swayidle` process, so that is
required. Turns on suspend again on click, and uses voidlinux `sv` user
service for it, so those have to be set up.
When creating a quick note with `nnn` on the command line, instead of
creating an 'untitled note' if no title is passed, we create a note that
is named after its creation date.
When in a ZK dir I do not want any marksman diagnostics polluting my
interface since the linking in (my) ZK is based on anchor IDs and not
full filenames/titles. Thus, every single link will be detected as
non-existent by marksman.
This commit ensures that when in a zk-enabled directory, each
non-existent link diagnostic will be filtered before presenting
diagnostics.
Invoked by `MOD+SHIFT+O` (for '[O]utput'), it greps the kanshi
configuration file for existing profiles and allows you to select one
which kanshi tries to apply. Can be a little buggy, though due to kanshi
and not the plugin (sometimes failing to re-activate turned off screens
etc).
