Gruaduate coloring in the preview buffer

[lordnik22]

depends #116

Graduate colouring would only work if live-stats are active.

Colouring of the characters in the preview buffer should depend on these live-stats (wpm). This should give a nice visualisation. It would be like a heat map. The faster the hotter. Important the colouring represents the speed not the accuracy. For undo to work correctly we may have to add a graduate-value (or directly the values on which the graduate coloring depend) as text-property to correctly determine the color. Else the only option would be to to reset to normal colouring which isn't consistent.
In a first we would graduate the color for following faces:

• speed-type-error-face (red)
• speed-type-consecutive-error-face (yellow)
• speed-type-correct-face (green)

Add an option to deactivate the gruaduate coloring. Maybe add an option to also have graduate-coloring directly in speed-type buffer.

Maybe add an option to also make the color depend on a mix of accuracy and speed.

Maybe add a second layer of color-mixing: If accuracy is bad, the green should have red influence. If the accuracy is good, the red should have green influence.

Maybe in show-inactive-region there is useful code for color grading:

• https://codeberg.org/ideasman42/emacs-show-inactive-region/src/commit/5e5db361ee93da72d96f2cc3d7c1c5bf52fbb96/show-inactive-region.el#L112

[lordnik22]

It must be decided at which values should turn the colour and how many colour grads are differentiable

The faster the saturated the green. The slower the fader the colour.

Maybe use a new face which inherits from dimmed. Similar as in the monkeytype package.

On https://colorbrewer2.org there are general colour recommendations. We should focus on 3-5 colour grades.

Colour grading:

1. Grade: 5 part of green (correct-face), 0 parts of grey (dimmed / info-face)
2. Grade: 4 part of green, 1 parts of grey
3. Grade: 3 part of green, 2 parts of grey
4. Grade: 2 part of green, 3 parts of grey
5. Grade: 1 part of green, 4 parts of grey

Maybe: A fancy way to pick the boundaries is if at each speed-type session the boundaries are calculated dynamically. So it's always a local speed-type session specific boundaries.

Dynamically calculated boundaries:

1. MAX
2. Upper Antenna
3. MEDIAN
4. Lower Antenna
5. MIN

OR

1. MAX
2. ROLLING MEAN + standard deviation
3. ROLLING MEAN
4. ROLLING MEAN - standard deviation
5. MIN

OR

1. MAX (95th percentile)
2. Upper Antenna (75th)
3. Exponential moving average
4. Lower Antenna (25th)
5. MIN (5th percentile)

Can this be performant calculated for each input else use fixed boundaries?

Dynamic boundaries are not comparable across sessions.

Fixed boundaries
WPM

1. <80
2. <75
3. <70
4. <60
5. <45

Accuracy

1. 100%
2. <98%
3. <95%
4. <92%
5. <90%