Yesteday I was musing about different input mechanisms for fiddling around with the look of charts. But then, while falling asleep, I thought “why not just put all the control in a buffer”, and so I did.
The result is on Microsoft Github, and it’s in a pretty rough state because I’m slightly busy today, but here’s a demonstration:
Eh? Eh? No, I don’t know either.
And now I’m off to wash the car.
I mean this is already more than good, but i think an ecomplete-aided font name selection would make it even better. Or a color-wheel for defining a color code.
Hm. Even a way to quickly and intuitively invoking `x-select-font’ would be useful.
It uses read-color to read colours, so I guess people can override that to have the colour picker of their choice?
Is there a read-font-name or equivalent somewhere? That’d be really useful.
Well, really read-font-family-name — we don’t need the exact font (with bold/italic/etc, but the family name. So x-select-font doesn’t really do the right thing here.
I’ve now implemented completion for systems that have the fc-list binary.
So that kinda sorta works now, but experimenting with this stuff has really brought home how many problems there are with the text-area-like approach the eww uses (and that I’ve used here, too). But I think I’ll actually try getting that fixed once and for all, and that’ll make things better in eww, too. (Possibly.)
That is, it uses read-color in the Transient interface. The new Controls interface doesn’t yet, but it’s planned.
I don’t know exactly the problem you were trying to solve but I would give what is demonstrated above a +1 just on the idea that having the tunables be in an interface like this implies some sort of input validation and thus is going to likely be a better UX than having the tunables be plain-text as a config file, Org Mode thing, set of variables to be setq’ed, YAML (shudder), etc.
I don’t know if that’s helpful perspective or not. Hopefully.