"GOT", but the "O" is a cute, smiling pufferfish. Index | Thread | Search

From:
Stefan Sperling <stsp@stsp.name>
Subject:
Re: [rfc] tog horizontal scroll (diff & blame view)
To:
Mark Jamsek <mark@jamsek.com>, gameoftrees@openbsd.org
Date:
Thu, 16 Jun 2022 10:29:20 +0200

Download raw body.

Thread
On Thu, Jun 16, 2022 at 10:10:13AM +0200, Stefan Sperling wrote:
> On Thu, Jun 16, 2022 at 05:48:03PM +1000, Mark Jamsek wrote:
> > On 22-06-16 09:35am, Stefan Sperling wrote:
> > > On Thu, Jun 16, 2022 at 09:15:24AM +0200, Stefan Sperling wrote:
> > > > In the blame view, in an 80x24 terminal, horizontal scrolling has a rendering
> > > > issue where separate lines get merged together. Even commit annotations are
> > > > move up and get merged to the end of the previous line.
> > > 
> > > The code forgot to subtract the leading part, before view->x, from
> > > the rendered line's width. Fix below works for me. ok?
> > 
> > Good catch! I forgot to offset the scrolled columns.
> > 
> > Because we've already passed the string to format_line(), this could
> > probably be simplified by just subtracting view->x:
> > 
> > 		if (width - view->x <= view->ncols - 1)
> 
> We must reduce the value of 'width' since 'width' it used again later.
> And to do that we need to know the width of the substring wline[0:view->x].
> This needs to be recomputed because otherwise we cannot tell how many
> columns of the total width the leading part of the string is using.
> Each wchar_t in this substring might using 0, 1, or 2 columns, and this
> property is unrelated to view->x.

Such issues also exists elsewhere. Try the attached repo which contains
some text from today's index page of ja.wikipedia.org. There are some
rendering issues to be observed, probably because substracting view->x
doesn't do the right thing in Japanese.

I'll try to come up with some fixes, but don't hesitate to take a look
if you have time :)