From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Native line numbers landed on master Date: Wed, 12 Jul 2017 17:40:10 +0300 Message-ID: <83fue1iur9.fsf@gnu.org> References: <83k23jl5ra.fsf@gnu.org> <87r2xqo8p7.fsf@lylat> <83lgnxk7v6.fsf@gnu.org> <87shi5jk2w.fsf@lylat> <83lgnwi3k3.fsf@gnu.org> <87a84crq31.fsf@lylat> <834lujj9d5.fsf@gnu.org> <87pod67lgi.fsf@lylat> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1499870737 27017 195.159.176.226 (12 Jul 2017 14:45:37 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 12 Jul 2017 14:45:37 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alex Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 12 16:45:32 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dVItO-0006dC-Ay for ged-emacs-devel@m.gmane.org; Wed, 12 Jul 2017 16:45:30 +0200 Original-Received: from localhost ([::1]:53871 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dVItT-0006xM-LQ for ged-emacs-devel@m.gmane.org; Wed, 12 Jul 2017 10:45:35 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60947) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dVIoM-0001Wg-Id for emacs-devel@gnu.org; Wed, 12 Jul 2017 10:40:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dVIoI-00059K-GJ for emacs-devel@gnu.org; Wed, 12 Jul 2017 10:40:18 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:52612) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dVIoI-00059B-Cl; Wed, 12 Jul 2017 10:40:14 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2684 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dVIoH-00067y-E2; Wed, 12 Jul 2017 10:40:14 -0400 In-reply-to: <87pod67lgi.fsf@lylat> (message from Alex on Tue, 11 Jul 2017 14:44:13 -0600) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:216540 Archived-At: > From: Alex > Cc: emacs-devel@gnu.org > 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.