Thanks Eli, that sounds carefully thought through and I agree with your
assessment.

Cheers!

On Fri, 30 Apr 2021, 19:36 Eli Zaretskii, <eliz@gnu.org> wrote:

> > From: Len Trigg <lenbok@gmail.com>
> > Date: Fri, 30 Apr 2021 10:29:23 +1200
> > Cc: 48095@debbugs.gnu.org
> >
> > That seems to work perfectly for my goal (and I assume the intent of
> display-line-numbers-width-start) of
> > having the width stay fixed unless content gets added to the buffer. It
> might help to add guidance in the docs
> > that extra lines would typically be set to the maximum window height.
>
> Thanks, I added that to the doc string.
>
> > Or maybe that value could instead be
> > automatically computed from the height of the tallest emacs frame at
> that time? I assume that's not too
> > intensive to determine since it happens once when the mode is activated?
>
> This would be over-engineering, IMO.  First, some people tend to have
> lots of frames, so this might be expensive.  Second, what matters is
> not the frame height but the window height, and we could have many
> windows even if the number of frames is small.  Third, some frames and
> windows could be dedicated to special displays, and thus not really
> relevant (example: Speedbar frames), so we will no doubt be asked to
> provide yet another defcustom, to let users control which frames are
> exempt from accounting for their height.
>
> So I think asking users to provide a value strikes a good balance
> between functionality and complexity, at least unless we hear about
> use cases where automatic adjustment would really make a lot of sense.
>
> With that in mind, I installed the change on the master branch, and
> I'm closing this bug report.
>