Open jkorinth opened 2 months ago
This looks simple enough, so why not.
This feature should be documented here.
To make testing easier, I would prefer to have a dedicated function called Edit: I see, you need mocking to test the extract_xresources_colors(content: &str) -> HashMap<String, String>
. Then in tests, you will not have to mock read_xresources
function, but instead just assert!
the contents of the returned hashmap.FromStr
impl.
Updated with the suggestions. There's no documentation for the 'hsv:` prefix, but I think that should go into a separate PR.
Btw: errors
deserves an overhaul, too, I think. Check out anyhow
and thiserror
, they eliminate most of the boiler plate.
Btw:
errors
deserves an overhaul, too, I think. Check outanyhow
andthiserror
, they eliminate most of the boiler plate.
I know about these crates and we use thiserror
already, in same cases. Creating an error enum for each block does not seem practical. We are not using anyhow
because in the past Error
struct used to contain a block: String
field. It no longer does (we now have a separate BlockError
for this, which uses thiserror
) and I think we can switch to anyhow
now.
LGTM. Just needs the CI to be passing.
LGTM. Just needs the CI to be passing.
How do you tell cspell to ignore words?
How do you tell cspell to ignore words?
Edit cspell.yaml
How do you tell cspell to ignore words?
Edit
cspell.yaml
Wait - cspell spellchecks not only the docs, but also the code itself?! And not just strings inside, but the full code? 😂
How do you tell cspell to ignore words?
Edit
cspell.yaml
Wait - cspell spellchecks not only the docs, but also the code itself?! And not just strings inside, but the full code? 😂
Yea, it is sometimes annoying, but now we have less typos in variable names, etc.
@jkorinth I've pushed a commit simplifying some stuff, can you review and test it?
Adds support to retrieve simple color definitions from
~/.Xresources
with a new prefix in the color definitions in theme overrides, e.g.,would look for a line like
in
~/.Xresources
.