Closed emmanueltouzery closed 1 year ago
To be explicit, this PR invokes the external program (glow) twice: indexed once up to the start of this section, once after. Then it counts the number of lines in the glow output for the first invokation, and positions the scroll not by searching, but by jumping to the right line offset (that we counted).
I used defer with a high value because sometimes the callback would not get called, if it's too short. It still happens with 500ms if the rendering is slow. I tried using schedule but it doesn't work. Making it configurable sounds like a good idea.
About the 500ms, note that this is a problem that goes away entirely with the other PR though, since we cut the output and therefore we don't need to scroll.
To be explicit, this PR invokes the external program (glow) twice: indexed once up to the start of this section, once after. Then it counts the number of lines in the glow output for the first invokation, and positions the scroll not by searching, but by jumping to the right line offset (that we counted).
It's definitely more complicated and that sounds like an overkill. I'd stick with the other PR.
Closing this PR as per your feedback 👍
more resilient section scrolling when using a previewer command: the search method often wouldn't work if the previewer commands changes the format enough. Fixes #28
Compared to #42 we continue outputing the whole text, which means the glow performance issues remain (although the latest git version is multiple orders of magnitude faster), but we don't have any issue in case the nature of the docs is to enable to scroll back.
I'm for now keeping both alternative PRs open, presumably pick the one that's the most promising to you.
The 500ms sleep time is a little high, I'd say. What do you think about lowering it, or maybe making it configurable?