A look at terminal emulators, part 1
A look at terminal emulators, part 1
Posted Mar 31, 2018 9:51 UTC (Sat) by grawity (subscriber, #80596)Parent article: A look at terminal emulators, part 1
Some terminals also parse the text for URL patterns to make them clickable. This is the case for all VTE-derived terminals
VTE also has an interesting feature in which the application itself can mark specific text as a clickable link, which is supported by ls --hyperlink
.
Enlightenment's Terminology has similar ad-hoc features using its own tools (tyls
, tycat
) and is oddly absent from the review completely. It would have been interesting to know where it ranks in terms of Unicode support. Its developers have refused to add a true-color mode, though.
Posted Apr 4, 2018 13:20 UTC (Wed)
by borisfaure (subscriber, #123474)
[Link] (1 responses)
Terminology does not support RTL scripts, but there's a bug open about it: https://phab.enlightenment.org/T5380 .
I have not refused to add a true-color mode.
I'd also be interested in benchmarks. On the ones I used, Terminology was a clear winner few years ago.
Posted Apr 17, 2018 20:18 UTC (Tue)
by Ross (guest, #4065)
[Link]
But that's an interesting point about color distances.
XTerm doesn't just use Euclidian distance. It's kind of messy. See allocateClosestRGB() for allocations and searchColors() for finding matches.
I'd immediately replace all of these, but there are two problems with the CIEDE2000 formula:
* it most likely assumes linear response per channel -- this is usually not true with raw RGB
* the formula would be very slow as they would require colorspace conversion in addition
The last formula in the Euclidian section which you mention looks reasonable, but the first issue
A look at terminal emulators, part 1
It does support Unicode but not combining characters (https://phab.enlightenment.org/T560). The test in the article should render correctly though.
It won't support it fully but it does approximate those TrueColors to a palette of 256 colors. It should do it better than XTerm since it is not using a dumb euclidean distance to compute color distance but something a bit more complex: the last formula on the Euclidean chapter on Color Distance on Wikipedia ( https://en.wikipedia.org/wiki/Color_difference#Euclidean ).
I know it's not perfect but having true-color support would imply too much work on EFL and I'm not confident on doing that soon. As usual, I'll be happy to review patches!
A look at terminal emulators, part 1
xtermClosestColor() does work as you suggest when matching colors on a paletted display (or if not compiled with DirectColor support). find_color_register() for graphics uses weighted Euclidian distance, and it doesn't seem to take advantage of DirectColor (that's my fault).
correcting for this is either a lookup table per channel (but it is hard to know which values to
plug in) or it isn't clear how to adapt the formula
to lots of multiplications, divisions, and square root operations in the computation itself
probably still applies. How do you handle that? How much better is it than the weighted Euclidian
distance? It would be nice to have a way to measure match quality to test various approximations.