| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
I'm working so much with markdown lately that I'd find it helpful if I
didn't have to think of every markdown rule myself.
|
|
|
|
| |
Looks useful, let's see.
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we use 256 color mode in XTerm, using LightBlue in Vim results in
0x5fd7ff but LightBlue in GUI mode will use 0xadd8e6 which has a low
contrast to the default color (0xbebebe).
Since my eyes are not getting better with age, I decided to go with the
old color code that provides better contrast even though I'm quite happy
with the rest of the "more nuanced" colors.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
|
| |
calling `execlineb -c` has unfortunate quoting issues, cause for
cornercases like arguments that contain spaces or `"` the result would
be a completely broken command line.
Instead, let’s do our own block construction in a small rust
program (for speed). I tried implementing it in bash first but even
prepending spaces to a string is a complete waste of time in that
language.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
As @aszlig mentioned earlier, this looks like a better plugin. It does
everything I need it to. This commit also enables `termguicolors` which
wasn't the case prior, and without it `vim-hexokinase` cannot function
properly.
|
|
|
|
|
|
|
|
|
|
| |
While ncurses already has support for detecting direct color terminals,
a lot of applications out there do not yet query terminfo but instead
rely on some shady COLORTERM environment variable. While I don't really
like that approach, patching XTerm to set that variable currently is
better than patching all the applications to query terminfo.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So far vim-css-color worked quite well for what I wanted, but after
talking to @devhell about possible alternatives, I stumbled upon
hexokinase and tried it a bit.
One of the gripes I had with things such as colorizer is that it
highlights colors regardless of the file types we're in, which in turn
will also highlight things where the hash character is not a hex value,
for example in Erlang's base notation for integers.
Hexokinase also highlights all file types but first of all, it only
highlights things separated by word boundary and also it's way less
obtrusive because the way I've configured it only the hash character is
highlighted, not the whole color value.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So far, the TERM environment variable has been set to xterm-256color,
but in reality newer XTerm versions already supported 24bit colors so
setting this to xterm-direct results in using the right terminfo entry
for our terminal.
To make sure this is really the case, let's explicitly set directColor
to true, because while it is enabled in nixpkgs by default it is however
a compile-time option and could possibly be disabled.
Additionally, Vim is now looking pretty gruesome because my colorscheme
so far has used colors for 16-color terminals and I don't particularly
like the GUI colors. I added a few fixups for the color scheme to
address that.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While I could have done this simply by setting the
g:markdown_fenced_languages variable, I instead decided it would be a
better idea to use the same language names that GitHub recognises via
their GitHub Flavored Markdown syntax.
Since they're using Linguist, I decided to simply import the YAML file
and try to match them against existing Vim syntax files. That way,
we only need to maintain a blacklist of languages we do not want and
should pretty much get highlighting for all supported languages.
Unfortunately, the "markdown.vim" syntax file sources all of the syntax
files for these languages and so the more languages we include there,
the slower it gets when opening a Markdown file.
Right now, I mostly use this for editing textareas, so let's see how
annoying the slower load time will get and blacklist more languages
later if it bugs me too much.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The file in question actually was a ZIP file, which instead of being
unpacked got directly moved to syntax/fish.vim and in turn caused errors
whenever the filetype was set to "fish".
Instead of just fixing up the ZIP file I switched to a GitHub repository
that seemed to be maintained a lot more (last commit in 2020) than the
one we had so far (last change 2013).
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
| |
The `colorizer` plugin doesn't produce accurate results, so I'll try
`vim-css-colors`. It's also looking more maintained than the previous
plugin.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Vim syntax highlighting plugin file is no longer[1] shipped with
Jinja2 version 3.x, so the build fails accordingly with:
install: cannot stat 'ext/Vim/jinja.vim': No such file or directory
In another upstream pull request[2] one of the project members mentioned
another syntax plugin which apparently seems to be more up to date. This
is what I'm hereby switching to as a replacement.
[1]: https://github.com/pallets/jinja/pull/1196
[2]: https://github.com/pallets/jinja/issues/1007
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
| |
I've been looking for a good, lightweight, and fast completion engine
that also has little or no dependencies. The `mucomplete` plugin seems
to fit the bill as I also don't have any fancy requirements.
|
| |
|
|
|
|
|
|
| |
I find myself working more and more with TOML files these days.
Unfortunately neither `vim` nor `neovim` upstream have added support for
syntax highlighting of TOML files yet.
|
| |
|
|
|
|
|
|
|
| |
This reverts commit 8ee2e8ee99e566f007051b9d1b51f6a14eb7b5f0.
pass 1.7.4 is in nixos-unstable now, so these changes are necessary to
fix the build of pass.
|
|
|
|
| |
This helps quite a lot when working with colors.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 88f3e07f175c813cd33469e426f76d7815dd1389.
Since https://github.com/NixOS/nixpkgs/pull/126616 still isn't merged
and also not in the current NixOS unstable channel, we run into the
following evaluation error:
assertion '(dmenuSupport -> (((dmenu != null) && (xdotool != null)) && x11Support))'
failed at: (17:1) in file: .../pkgs/tools/security/pass/default.nix
I decided to re-revert this change, because the commit in question
(which undid the revert) did not specify a good reason for doing so and
right now the eval error breaks all machine channels on Hydra.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @sternenseemann
|
|
|
|
|
|
|
|
|
|
|
|
| |
Another alias that has been introduced not too long ago[1] and now more
closely resembles the actual command name. Since NixOS VM tests no
longer allow aliases, our sandbox tests did not evaluate anymore.
While at it, I also renamed all the other uses of the alias.
[1]: https://github.com/NixOS/nixpkgs/commit/726306003af21ade95b1908d1920ce9a0f9815bb
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is another alias which got introduced in 2018, because the actual
command is "pkg-config" and so the package name containing a dash is
more reasonable.
The reason why I'm doing this is because NixOS VM tests now disallow
aliases and while the evaluation error in question only affected the
"gnupg" test, I decided to change all occurences in the event that we
might want to disallow aliases for things other than VM tests.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @sternenseemann for "opam-env"
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Similar to 4701a995cb865c5d7178f574a3eae5872595e768, where I replaced
the libtidy alias for html-tidy because it broke evaluation of the PSI
test, I found another test for nman which uses an alias.
The background is that aliases are now[1] no longer allowed in NixOS VM
tests and since "s6PortableUtils" is indirectly referenced, we get an
evaluation error on Hydra.
Using the unaliased name fixes evaluation and should not change anything
in functionality.
[1]: https://github.com/NixOS/nixpkgs/commit/3edde6562e19698da69a499881e0a2e4f5a497a2
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @Profpatsch
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is mainly to incorporate my latest fix[1] for OMEMO, so in theory
updating the plugins would have been sufficient. However, since I like
to eat the freshest set of new bugs, I also updated everything else
except the theme. The latter seems to be a bit more complicated, since
it changed the way they're building it so I skipped that for now.
[1]: https://github.com/psi-im/plugins/pull/91
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A recent change[1] disabled aliases by default in VM tests and since
libtidy actually has been an alias of html-tidy since 2014 it's a good
idea to use the actual non-aliased packaged.
Since I added my PSI build in 2019, I probably didn't check for whether
the package name in nixpkgs would be different while packaging and only
used the name as reported by CMake, thinking it would work (which it
did).
Disallowing aliases in VM tests however is a good change, so let's use
the real package name.
This should fix the evaluation of the Hydra jobset.
[1]: https://github.com/NixOS/nixpkgs/commit/3edde6562e19698da69a499881e0a2e4f5a497a2
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
| |
Since this package is introduced via an overlay expression pulled in via
IFD, I can't really fix it. Since dhall-flycheck has already been
removed from all machines it was a part of, just remove it completely to
migitate this issue.
cc @Profpatsch
|
|
|
|
| |
This reverts commit c11bd9ec702c71e731cb14c26ff235ea1956a613.
|
|
|
|
|
|
| |
This reverts commit 1987f2d9a4b185dfa319763a67d527fd7ade4d83.
This is not even merged into master yet, pushed by mistake.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
A simple text letter formatter (A4) for printing.
|
|
|
|
|
|
| |
The concept of a transparent handler wasn’t actually used anywhere and
now that we want to generate the firefox json as well, it just hinders
us from doing that in an easy way.
|
|
|
|
|
|
| |
The type string would blow up too much if you can’t reference any
dhall file in the sources list. This all feels a bit hacky, but at
least semantically it seems to work out?
|
|
|
|
|
|
|
| |
No use in passing through the mime type now that we can just directly
render the commands in the protocol handlers.
This gives us the base for generating the Firefox handlers.json.
|
|
|
|
| |
Removes the duplication of command handlers.
|
|
|
|
|
|
|
|
|
| |
This diff is a bit bad cause of whitespace changes, but effectively
this copies all handlers into the mime handler definitions and
duplicates them for now.
We want to use the same config to generate a firefox mime handler
file.
|
| |
|
|
|
|
|
|
| |
testRustSimple wouldn’t work with all the rust functions, so let’s
just use it internally and expose the tests via the conventional
`doCheck` attribute instead.
|
|
|
|
| |
Just to prove I can.
|
|
|
|
|
|
|
|
| |
The -T flag is GNU coreutils specific, for s6-ln and POSIX ln, the equivalent
seems to be -L which mandates behavior like linkat(3) with the AT_SYMLINK_FOLLOW
flag.
cc @Profpatsch
|