jq
jq copied to clipboard
jqlang
Set field color using JQ_COLORS
This should address #1739.
As far as I can tell, this works and passes the test suite (which I updated to test this specific addition). There is a chance that the code changes are not perfect; for example I'm not sure how much sense it makes to have introduced an enum member JV_KIND_FIELD for this (although it keeps the code mostly regular).
Coverage remained the same at 84.457% when pulling 0d53abc635a6d331522e756d8e0fe23d7760496e on haguenau:feature/set-field-color into 4b4fefa254346524c787b862e35e4fbb70e01e95 on stedolan:master.
Interesting. Obviously there is no use for this new "kind" other than as an index into the array of colors. I'll think about it. Thanks for your contribution!
Cool. Please don't hesitate to let me know if you see changes that you think would make sense.
@nicowilliams , would you be willing to merge an updated version of this patch or even https://github.com/stedolan/jq/pull/1977?
I'm attaching a patch that's a updated version of this PR for anyone that builds jq themselves. Thanks, @haguenau, for the original code.
jq-src-JQ_COLORS-field-color.patch.txt
EDIT: I noticed that in cf615152e192729541db6c06f0c009e2898b1c4e, jq.1.prebuilt was not updated with the new default scheme.
Depends on what you mean by abandoned. I'm still using this patch, and the last time I synchronized my copy of jq with the upstream repo (December), the patch still applied cleanly, so I haven't needed to post any updates here.
is this abandoned?
I see commits on the repo as recently as a month and a half ago... guessing the dev's are just busy / this isn't a high priority for them. I'm not familar with travis builds but I see that it has something flagged for:
continuous-integration/travis-ci/pr — The Travis CI build could not complete due to an error"
It could be something as simple as that holding things back.
Anyway, I hope folks are able to make it happen too... can't stand the hard-to-read dark blue key/property names on my terminal. Even if the default was a bright purple, that would at least have decent contrast on light and dark backgrounds. Obviously customizing would be better but I probably wouldn't have bothered to look this up / subscribe to the ticket and PR if the defaults were more reasonable :-)
Guess it's back to alias jq='/usr/bin/jq --monochrome-output' for me until this makes it in / someone posts idiot-proof build instructions that I can follow for patching lol
I have not followed jq development very closely since submitting this pull request two years ago. I must admit I do not fully understand nicowilliam's reasons for having to think more about this; I assume the change is somehow unclean.
If there is interest, I would be happy to look into reworking the change so that it applies successfully to the current code.
I would, too, be very interested in hearing counter-arguments against this. The hard-coded field color is very difficult to read on a dark background, and dark backgrounds are pretty common in what I would assume jq's user base is.
Changing the field color is also something quite a few people request in https://stackoverflow.com/questions/51338701/how-do-i-customize-the-colors-used-by-jq-c
I'll open a PR later today with my latest version of the patch.
Much appreciated. Given how old this pull request is, I expect a lot of changes would be needed to make it up to date, so I am very happy to see you offer to take care of this.
Taking a careful look into this patch, I finally understand why this is hard to merge. This patch adds JV_KIND_FIELD to jv_kind, but this is not what jv_kind is intended. This enum type is a basic and core type of JSON representation in jq, and such a new value shouldn't be added just for colors. So I propose; do not touch jv_kind and color_kinds, but color_bufs can have 8 (==sizeof(color_kinds)/sizeof(color_kinds[0]) + 1) entries, and FIELD_COLOR can be colors[sizeof(color_kinds)/sizeof(color_kinds[0])] or simply colors[7].