GNU bug report logs - #48095
28.0.50; display-line-numbers-mode / display-line-numbers-width-start incorrect

Previous Next

Full log

Message #19 received at 48095-done <at> debbugs.gnu.org (full text, mbox):

From: Len Trigg <lenbok <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 48095-done <at> debbugs.gnu.org
Subject: Re: bug#48095: 28.0.50; display-line-numbers-mode /
 display-line-numbers-width-start incorrect
Date: Fri, 30 Apr 2021 22:56:15 +1200

[Message part 1 (text/plain, inline)]

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

Cheers!

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

> > From: Len Trigg <lenbok <at> gmail.com>
> > Date: Fri, 30 Apr 2021 10:29:23 +1200
> > Cc: 48095 <at> 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.
>

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.