Fixed text not flowing to the external (nvim) editor and saved text not
being brought back into qutebrowser.
Same issue as here https://github.com/qutebrowser/qutebrowser/issues/6707
it essentially amounts to the terminal not having its own running
process id which qutebrowser uses to know when the application closes.
Thus, it thinks it closes immediately and deletes the temporary file. No
changes are brought back and the file is empty for the editor.
With the fix, this does not happen anymore.
If we call the listing and applying function directly we either select a
random colorscheme on *no* selection or we have to make use of either
xargs GNU functionality or something like moreutils ifne to only select
color schemes on selection.
Can additionally set a random theme (if selection is 'random') or a
random light theme (if selection is 'light').
Switching from my custom, brittle, styling implementation `styler` to
the wonder `flavours` program which does exactly the same only with more
clarity, faster and - I would presume - more stable.
Neovim will source the `colorscheme.lua` file in its state directory on
startup, as well as whenever the file contents are changed.
This allows any colorscheme definition to be put into the file and vim
will apply it as soon as the file contents change.
Instead of checking for the specific DP-3 and DP-5 setup that my two
screens default to, we just check that two DP- monitors are connected
and set up the wallpapers on them.
This also circumvents the issue that screens receive different numbering
when disconnected and reconnected at any point.
Using the lazy option 'version' we default to updating only to the
latest stable (semver) version of plugins. This should make it a little
more stable in the long run to keep up with plugin updates.
Not all plugins support this versioning scheme and for those that do not
it just keeps tracking the main branch.
Currently from the plugins that support it, only `nvim-lspconfig` needs
to be manually kept on the main branch since it is missing the correct
lua language server otherwise. This should be a problem of the past with
the release of the next version of the plugin.
cmp-pandoc.nvim did not work sufficiently for my use case so far
(sometimes it did, most of the times it did not at all, every now and
again it sputtered some references to the list).
cmp-pandoc-references seems like a plugin kept relatively 'simple'
requiring no setup, a single `bibliography: ` line in the pandoc
meta-data header and it works flawlessly from there. I might delve
deeper at some point, especially with the papis.nvim integration, but
for now this is perfectly adequate.
Marty Oehme