The swatch capability is pretty ancient has never gotten much attention, this seems like a previously unknown limitation. [1] I’d suggest you file a GitHub Issue with full details, most especially a complete Minimal Reproducible Example.
glancing at the codepath it appears that if a swatch specification is found then further processing of the former string stops. ↩︎
This is my first time submitting an official bug, and since it seems like a fairly simple one, is there anyway I can help fix it? Do I need to wait for the bug to be placed on the task list?
This would be my first time attempting to contribute, so I want to get my feet wet with something relatively light.
I really appreciate your enthusiasm @Gen! In this case, however, I actually plan to open a discussion about deprecating and removing the $swatch special variable, and replacing it with techniques that are are more in line with modern Bokeh. The old $swatch has a number of deficiencies:
not configurable at all (size, shape, etc)
has obscure syntax that is hard to document/discover
adds complexity internally that is undesirable
Better would be to make CustomJSHover a workable option so that users can self-serve any needs they have, or else add actual formatter models for color values, that can be used in the same way that all other custom formatters work these days.
If you want to join the Bokeh dev slack we can try to chat about other possible issues based on you interests/experience.
@Bryan Thanks!
I’ll join the devstack…I just want to slowly work my way up thru the codebase.
Regarding $swatch, completely understood. I thought it was fairly clunky that this, and only this, $swatch field needed a colon to another color column. Removing/rewriting it seems correct (at least from the user perspective, haven’t looked at the code)