Feature Request: Synchronize number of lines between two side-by-side codeblocks with word-wrap

[brianjenkins94]

(Left example taken from https://codehike.org/docs/code/word-wrap and squishing it)

 1 function lorem(ipsum,     | # This line happens to fit    |
   dolor, sit) {             |   comfortably                 |
 2   ipsum.amet(             |                               |
 3     { consectetur: [0, 1] | # This line is also fine      |
       },                    |                               |
 4     {                     | # This line is too long and   |
 ·                           |   pushes the left down (but   |
 ·                           |   doesn't change its content) |
 5       adipiscing:         |                               |
         elit.sed,           |                               |
 6       eiusmod: "lorem     |                               |
         ipsum dolor sit     |                               |
         amet",              |                               |
 7       sit,                |                               |
 8     },                    |                               |
 9   )                       |                               |
10 }                         |                               |

Sites like https://www.diffchecker.com/ are able to do this to display side-by-side diffs. My use case more closely relates to literate programming.

The gist being: two arbitrarily wide codeblocks with word-wrap should be able to be displayed side-by-side but still have longer lines alongside eachother.

[brianjenkins94]

CodeSandbox

[brianjenkins94]

Any interest in this as a feature or thoughts on the above implementation?

Right now it doesn't support AnnotationHandlers, unfortunately.

Would be nice to be able to collapse ranges simultaneously.

[pomber]

Hi! looks good.
I don't see it as a codehike feature, the goal of codehike is to be flexible enough to let you build UIs like that one in userland.

[brianjenkins94]

Ah, so if I had more closely modeled my implementation after InnerPre/Line/Token then maybe AnnotationHandler s could still work?

That makes a lot of sense in hindsight.

I suppose it's also probable that trying to make it work the way it's currently written could have ended up taking more effort than just reimplementing AnnotationHandler functionality.