Download raw body.
[rfc] tog horizontal scroll (diff & blame view)
On 22-06-15 04:52pm, Stefan Sperling wrote: > On Thu, Jun 16, 2022 at 12:04:17AM +1000, Mark Jamsek wrote: > > This patch introduces support for horizontal scrolling in diff and blame > > views. > > > > New key maps: > > > > h - scroll left (left arrow works too) > > l - scroll right (right arrow works too) > > 0 - scroll to the beginning of the line > > $ - scroll to the end of longest line on screen > > The $ key triggers scrolling to the right even if all lines fit within > the current width of the window. I am not sure if this is intended. > > As an example, in a hypothetical small 8 columns diff/blame view, > and with just one line in the file: > > 12345678 > foobar > > Hitting '$' now results in something like this, where it seems to > scroll to roughly the middle of the line: > > 12345678 > bar > > Whereas I would expect it to work like this: > > Given: > > 12345678 > foobar > > Hit '$' -> no change since the line already fits > > But in this situation: > > 12345678....<- columns with dots are offscreen > foobarbazboo > > The result of '$' I expect would be: > > 12345678 > arbazboo > > Does this make sense? > Or is there something wrong in my assumptions? > That's intended; I figured we should still let it scroll assuming the user wants to focus on the end of the line. For instance, I tend to like keeping my focus on the first third of the screen width. So I've made it to scroll so that the end of the line will remain roughly in that area. But if you think we should not scroll at all if the line fits on the screen, I'm happy to do that too. > > +static uint16_t > > +expanded_strsz(const char *str, unsigned short n) > > +{ > > + uint16_t i = 0; > > + > > + while (str && (str[i] != '\n' && str[i] != '\0')) { > > + if (str[i] == '\t') > > + n += 8 - (i % 8); /* expand tabs */ > > + if ((str[i] & 0xc0) == 0x80) > > + --n; /* utf8 continutation byte */ > > + ++i; > > + } > > + > > + return n; > > This code should work fine on OpenBSD. However, Got -portable might > be running on systems which use non-UTF8 locales. For this reason, > it might be better to use wchar_t and wcwidth() to determine the > display length of the expanded version of the string. It would then > work on OpenBSD and everywhere else, and less work would be required > for the -portable version. > Okay. It's late here and I was just about to hit the sack but I should be able to change this tomorrow evening. Thanks, Stefan! -- Mark Jamsek GPG: F2FF 13DE 6A06 C471 CA80 E6E2 2930 DC66 86EE CF68
[rfc] tog horizontal scroll (diff & blame view)