Re: Native line numbers landed on master

[Eli Zaretskii]

> From: Alex <address@hidden>
> Cc: address@hidden
> Date: Tue, 11 Jul 2017 14:44:13 -0600
> 
> > Sounds OK to me, thanks.  I think we do want all the variables to
> > appear in the same customization group, even if they are defined
> > separately.
> 
> Well, it seems this cus-edit change doesn't fix it by itself. When
> executing customize-group without display-line-numbers loaded, then the
> lisp-level defcustoms aren't shown. It might be because there's a
> missing entry in cus-load.el, but I don't know how to add a group to it.
> linum, for instance, appears to automatically be added to it.

cus-load.el is auto-generated.  Did the rule which updates it in
lisp/Makefile get running after your changes, and was cus-load.el
regenerated as result?  If not, maybe you need to run that rule by
hand.

> Would it be better to skip creating a new defgroup and have all
> variables just be in the display group, or are you in favour of a new
> group just for line numbers?

If it's a hassle to make a new group, we can stay in the display
group.

> >   M-x set-variable RET display-line-numbers RET t RET
> >
> > This is a legitimate way of activating the feature in a buffer.  Do we
> > want then the user to automatically have access to all the
> > customizations and features in display-line-numbers.el?
> 
> As is stands, the contents of display-line-numbers.el only applies to
> the minor modes and not display-line-numbers itself. So the user would
> have to call one of the minor modes to use the features, and at that
> point everything will be loaded.

OK.

> > That was to fix a bug that I think shouldn't happen with the native
> > implementation, because it doesn't count lines.
> 
> So even a single count-lines on the whole buffer is too much?

No, it isn't.  Feel free to leave it, I will look into that when I
have time.

> I've attached an updated patch. I didn't update the commit message yet.

LGTM, thanks.