Handle 48-bit #rrrrggggbbbb hashes (fixes rainbow-identifiers-mode) #30
Conversation
These aren't valid in HTML so we shouldn't be passing them through. (color-values) will read these, so just fall through to that if we encounter one.
| ;; returns nil. | ||
| ) | ||
| ((string-match "\\`#" color) | ||
| ((and (string-match "\\`#" color) (= (length color) 7)) |
There was a problem hiding this comment.
Should we just convert #rrrrggggbbbb to #rrggbb?
I think the idea behind this code is to handle color names like "fuchsia" without calling color-values which (at some point) didn't work when Emacs was run from a TTY. Perhaps the whole logic of parsing rgb.txt can just be removed.
There was a problem hiding this comment.
I don't have any background on the history there, but sticking the (not (string-match ...) on the rgb.txt condition means only strings that start with # but are not the expected length fall through to color-values, which should handle them (though maybe older emacs had some caveats there?)
As a side-effect, actually, this will cause #111 12-bit colors to go to color-values too, and expand to 24-bit. Maybe that's okay for consistency? Or we could allow lengths of 7-or-4.
I'm happy to tweak this however you think it should go -- a replace-regexp-in-string to just truncate the least significant bits down from the 48-bit ones would work, too.
* htmlize.el (htmlize-color-to-rgb): Only leave #XXXXXX color hashes as is. Use rgb.txt or `color-values' to obtain appropriate #XXXXXX hash for non-standard colors (e.g. #rrrrggggbbbb or #AAA). Alternative fix for #30.
|
@tarsius Here is a slightly different fix, with more strict regexp. I think it should be fairly safe. |
|
Please go ahead and push that. |
4 participants
There's a few different ways to write this
(cond), I went for the minimal change here but it could be re-ordered to be a little clearer.This fixes, specifically, htmlize-ing code with the rainbow identifiers package, which emits these colors.