On 22-08-13 12:01PM, Stefan Sperling wrote:
> On Sat, Aug 13, 2022 at 11:39:17AM +0200, Stefan Sperling wrote:
> > On Fri, Aug 12, 2022 at 11:36:46PM +0200, Stefan Sperling wrote:
> > > Here is a case where movement doesn't seem to work while loading:
> > > 
> > > 	tog log path
> > > 
> > > Where path is any file in a deep history that has seen few changes.
> > > The top-level Makefile in OpenBSD src.git is one such file.
> > 
> > This can be fixed by... well, simply not waiting for the log thread.
> > 
> > In hindsight, the articicial blocking behaviour was probably a bad idea.
> > If we remove related code, the tog log view remains responsive at all times.
> 
> This patch causes an issue when the cursor is on the last loaded and displayed
> commit sits at the bottom of the terminal, and the user scrolls down one step.
> The log view no longer loads _and_ scrolls with a single key press. Instead,
> the first key press loads a commit but the cursor remains at its position.
> A second key press is needed to scroll the window. The previous behaviour made
> more sense in this particular case. However, we can probably emulate it somehow
> without blocking any other action (which is bad in case the next commit takes,
> say, 30 seconds to load). Instead, could we somehow trigger a scroll event in
> case a commit has been loaded off-screen after a scroll-down request, and the
> cursor has not been moved since... ?

Hmm...I see what you mean. Definitely not as intuitive as the previous
behaviour. The solution I'm thinking of now feels really hacky so I'll
have to think about it some more. Apart from that issue, it also makes
nG behave a bit weird sometimes too:

  $ tog
  100G
  *only moves to the 2nd commit*
  100G
  *now it moves to the 100th commit*

Otherwise it works great! We just need to find a solution to these
couple quirks.

-- 
Mark Jamsek <fnc.bsdbox.org>
GPG: F2FF 13DE 6A06 C471 CA80  E6E2 2930 DC66 86EE CF68