search

kaievns / git-wayback-machine

A simple script to quickly navigate a project's state through it's GIT history
159 stars 13 forks source link

Screen corruption on long lines and up/down arrow esc keys showing #4

Closed markjfisher closed 9 years ago

markjfisher commented 9 years ago

Platform: OSX Installed version: git-wayback-machine-0.1.1.gem

Scrolling through commits with long lines leaves screen corruption

There's 2 parts to this problem:

  1. The right hand side of screen corruption showing text from other commits when scrolling over lots of commits
  2. When pressing arrows quickly to scroll down, as the screen is rotating through the fixed size block the control keys appear at the bottom

git-wayback-corruption

kaievns commented 9 years ago

i see. we probably need to cut the string length by the screen width

thanks for reporting!

kaievns commented 9 years ago

hey mark, could you please that version 0.1.2 fixes the issue? thanks!

markjfisher commented 9 years ago

The RHS corruption is gone, but still lots of issues.

Here's a screenshot after resizing my iTerm2 window.

git-wayback-corruption2

What happened after I changed window size is:

  1. the top section (coloured red) line wrapped to the new width, leaving large blank lines between elements when the size was reduced (as the lines appear to be a given width, so reducing window width causes the wrapping)
  2. When I then pressed up/down arrows the new width was used to then display a new section below the line-wrapped one. The top section is now fixed and stays on the screen while the bottom section is the "active" history that reacts to key movements.
  3. At this point, if I increase the frame width, the "active" list expands out and doesn't align properly until I press up/down (see next shot)

git-wayback-corruption3

Also note that occasionally the esc sequence for the up/down keys corrupt the display (^[[B everywhere)

kaievns commented 9 years ago

Hey Mark,

I’m afraid corruptions from resizing the window are inevitable. AFAIK you can’t track a window resize from inside of a ruby process. so it can only redraw itself if you press up/down, and it might leave some of the lines afterwards.

The best you can do is to hit ctrl+c and then ctrl+k to clear up the screen. and then restart the process.

On Jun 30, 2015, at 7:39 PM, Mark Fisher notifications@github.com wrote:

The RHS corruption is gone, but still lots of issues.

Here's a screenshot after resizing my iTerm2 window.

https://cloud.githubusercontent.com/assets/1616940/8427408/dc1b031e-1f0e-11e5-83aa-12476f3353ba.jpg What happened after I changed window size is:

the top section (coloured red) line wrapped to the new width, leaving large blank lines between elements when the size was reduced (as the lines appear to be a given width, so reducing window width causes the wrapping) When I then pressed up/down arrows the new width was used to then display a new section below the line-wrapped one. The top section is now fixed and stays on the screen while the bottom section is the "active" history that reacts to key movements. At this point, if I increase the frame width, the "active" list expands out and doesn't align properly until I press up/down (see next shot) https://cloud.githubusercontent.com/assets/1616940/8428138/526138cc-1f14-11e5-8876-efe880970177.jpg — Reply to this email directly or view it on GitHub https://github.com/MadRabbit/git-wayback-machine/issues/4#issuecomment-117093920.