On Thu, Jun 16, 2022 at 01:04:58AM +1000, Mark Jamsek wrote:
> > 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.

There is no wrong or right way to do this.
I am fine with the way it is behaving now. Thinking some more about it,
it seems nice that horizontal movement is always possible even if the
lines already fit on the screen. This makes it much easier for users
to discover the existence of this feature just by pressing buttons.

My expectations about the behaviour of $ were based on the documentation:
"scrolls to the end of the longest line".
Maybe we should rephrase this? Something like "scrolls the view to the
right-most position", without an explicit hint as to where this position
might be anchored in the scrolling logic? Effectively, $ is just a
short-cut for pressing right-arrow a lot of times, right?
 
> > > +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!

Sure, no rush. Thank you for working on this. It is a feature I've
always wanted. I even took a stab at this myself once, but did not
get to working code very fast and ran out of motivation.

I would also appreciate a rebased version of your last-modififed date
patch for the ref view.