emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Native line numbers landed on master


From: Alex
Subject: Re: Native line numbers landed on master
Date: Tue, 11 Jul 2017 14:44:13 -0600
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> From: Alex <address@hidden>
>> Cc: address@hidden
>> Date: Mon, 10 Jul 2017 14:31:46 -0600
>> 
>> I'm not sure if there's a convention for this (built-in feature with a
>> Lisp-level mode wrapper) situation, but it might be nice to separate the
>> variables that are directly linked to display-line-numbers and ones that
>> only are used in the minor mode wrapper.
>> 
>> What about defining the defgroup in cus-edit.el, making both these
>> variables and the ones in cus-start belong to it?
>
> 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.

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?

>> I don't know if the file should be pre/auto-loaded. Is there a reason to
>> do so considering linum.el isn't?
>
> linum.el _is_ autoloaded if you invoke linum-mode, no?

Right, I was referring to the defcustoms.

> The scenario I had in mind was a user doing this:
>
>   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.

I thought about autoloading the defcustoms, but it seems as if that's a
contentious decision[1].

> 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?

>> Does the problem affect display-line-numbers?
>
> I don't think so, but it should be easy to test.  I'll take a look.

If so, then I'll leave it in.

>> P.S. I also noticed that the docstring for display-line-numbers doesn't
>> describe the 'relative value, or state that 'visual also uses relative
>> line numbers.
>
> Thanks, I fixed this.

Thanks, though it seems like your copyedit commit introduced a couple
typos. It also doesn't mention that any other non-nil value is treated
as t.

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

Attachment: 0001-Add-minor-mode-interface-for-display-line-numbers.patch
Description: v2

Footnotes: 
[1]  https://emacs.stackexchange.com/a/32860


reply via email to

[Prev in Thread] Current Thread [Next in Thread]