From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.devel Subject: Re: Native line numbers landed on master Date: Fri, 4 Oct 2019 19:28:21 +0200 Message-ID: References: <834l4xbfmp.fsf@gnu.org> <87ef414dfn.fsf@wavexx.thregr.org> <83o9359w3l.fsf@gnu.org> <83eezycce5.fsf@gnu.org> <87muekj0i9.fsf@wavexx.thregr.org> <87d0fgagjl.fsf@gnus.org> <20191001225254.mwjnxlynjdc3mz7y@Ergus> <83lfu389vn.fsf@gnu.org> <87bluxg1b5.fsf@wavexx.thregr.org> <83blux7jvz.fsf@gnu.org> <877e5ksdtr.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000091978605941909f5" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="139875"; mail-complaints-to="usenet@blaine.gmane.org" Cc: spacibba@aol.com, yuri.v.khan@gmail.com, Yuri D'Elia , Lars Magne Ingebrigtsen , Emacs developers , Eli Zaretskii To: =?UTF-8?Q?Johan_Bockg=C3=A5rd?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 04 19:30:47 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iGRPj-000aGJ-39 for ged-emacs-devel@m.gmane.org; Fri, 04 Oct 2019 19:30:47 +0200 Original-Received: from localhost ([::1]:50764 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iGRPh-0005eF-Py for ged-emacs-devel@m.gmane.org; Fri, 04 Oct 2019 13:30:45 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54658) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iGRO9-0005dz-QK for emacs-devel@gnu.org; Fri, 04 Oct 2019 13:29:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iGRO7-0002zQ-G4 for emacs-devel@gnu.org; Fri, 04 Oct 2019 13:29:09 -0400 Original-Received: from mail-qk1-x741.google.com ([2607:f8b0:4864:20::741]:46335) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iGRO3-0002qI-AN; Fri, 04 Oct 2019 13:29:03 -0400 Original-Received: by mail-qk1-x741.google.com with SMTP id 201so6480720qkd.13; Fri, 04 Oct 2019 10:29:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=prCygGEDtmxhHkPjRdAHl5sNHBSklGRqGPc17IfZJx0=; b=cjMBNbaT1B5gZdbvXBhlW1WXlmgX8f2mQpem30ozig2TXf0/HtCPMTWFmhinTuDUJA 6ULEHB6fw3PupUI86qXmZkLnEsUn/Y2xCAU6r+VHq4eDQmJpqAe6pKy6XiwHzmOlOqaI RMy8aqXYRyQ2sBlonm+VSjz7SzawtKR7xg84xB1BfKMNWw6KSkjC7+NSJk/PfqH+J6kR tAsAvRbqPt7Kj/rggM+GtWVr7T5rkFKANmisrusLcvaowxDQt7kO4dG/gGokh9jxa1wD KMHKic4Dy51LOESCndVl66TRgVOXrrmM03SXNyjKUPIN9Rox6V2AVAFrOUcTS+GGRUX1 tJOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=prCygGEDtmxhHkPjRdAHl5sNHBSklGRqGPc17IfZJx0=; b=IcyJTpjskBmgooqSrKZKoJ+ObA2Sz/tD2SQTM30uyBIn5Mwh6KNkO2YLl3OUmfHDGJ JxO4365AYjBQ22P8GCI9ZyH8zXyPXaSoWHFEKkMbyFIXQhTwQJb/r3q/EshHKRzgK2CI iNgZ7hsWK6gc6jWSjono/eZaqvhFywVibh/Ec/d4nZHakevzCz0NNhlXqFVpadK5YvHS TUM+1sXD/eaQOd8IR3hhsNgCJ2I6APc6Z52pkKYSO+4HEe3Ubg1svWsJnmqmZCqMpq7t mK8+jsQT+Fvg4+KXTylfHrabtdUOkDx7q9hvDDVfJjTPOnTAV6DV62PmZPlZ0ReyBnMs BwHg== X-Gm-Message-State: APjAAAV1o+o1mmgHK1Kn1iA5c5bxjGokF3jXDlzuKFVD9iyHp9W0ZQvM jfYHyudzi489rIX901ZhUVFw4rZA4/3IiUfMd49AZw== X-Google-Smtp-Source: APXvYqxL8r/Kvfr0pzXR6fyMc39f+T47t8MnICWevV3kYokVLk13FKrbR5775i885zlvW8c21PPamDSOE0j9CY/xPOM= X-Received: by 2002:a05:620a:6db:: with SMTP id 27mr10961376qky.281.1570210139181; Fri, 04 Oct 2019 10:28:59 -0700 (PDT) In-Reply-To: <877e5ksdtr.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::741 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:240577 Archived-At: --00000000000091978605941909f5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Oct 4, 2019 at 5:58 PM Johan Bockg=C3=A5rd wrote: > > Juanma Barranquero writes: > Why not use DEFVAR_INT? My feeling is that DEFVAR_INT is appropriate for variables that must always have a number, like display-line-numbers-offset in the next patch. Even its "off" value is just having an offset of 0. On the other hand, ticks can be turned on and off, and though strictly speaking 0 can serve as off, it seems cleaner to allow the user to set them to nil to turn them off. That said, I don't feel strongly about it. I'll got with the consensus. > I realize that many existing variables in xdisp.c don't follow this > recommendation, but the manual says the following: > > *Warning:* Don=E2=80=99t assume that you should use > =E2=80=98make-variable-buffer-local=E2=80=99 for user-option variabl= es, simply > because users _might_ want to customize them differently in > different buffers. Users can make any variable local, when they > wish to. It is better to leave the choice to them. I know the recommendation, but the reason many variables don't follow it is that it is less convenient. In cases like this one, I think it's quite likely that the tick values will depend on the mode or the kind of data, or even its length (Yuri said that he uses large values to quickly scan log files, for example). When seems likely that every buffer will have its own value, I strongly believe it's cleaner to have the variable automatically buffer-local. --00000000000091978605941909f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Fri, Oct 4, 2019 at 5:58 PM Johan Bockg=C3=A5rd <= ;bojohan@gnu.org> wrote:
><= br>> Juanma Barranquero <lekktu@g= mail.com> writes:

> Why not use DEFVAR_INT?

My feeling is that DEFVAR_INT is appropriate for variables that mu= st always have a number, like display-line-numbers-offset in the next patch= . Even its "off" value is just having an offset of 0.
<= br>
On the other hand, ticks can be turned on and off, and though= strictly speaking 0 can serve as off, it seems cleaner to allow the user t= o set them to nil to turn them off.

That said, I d= on't feel strongly about it. I'll got with the consensus.

> I realize that many existing variables in xdisp.c don&= #39;t follow this
> recommendation, but the manual says the following= :
>
> =C2=A0 =C2=A0 =C2=A0*Warning:* Don=E2=80=99t assume that = you should use
> =C2=A0 =C2=A0 =C2=A0=E2=80=98make-variable-buffer-lo= cal=E2=80=99 for user-option variables, simply
> =C2=A0 =C2=A0 =C2=A0= because users _might_ want to customize them differently in
> =C2=A0 = =C2=A0 =C2=A0different buffers.=C2=A0 Users can make any variable local, wh= en they
> =C2=A0 =C2=A0 =C2=A0wish to.=C2=A0 It is better to leave th= e choice to them.

I know the recommendation, b= ut the reason many variables don't follow it is that it is less conveni= ent. In cases like this one, I think it's quite likely that the tick va= lues will depend on the mode or the kind of data, or even its length (Yuri = said that he uses large values to quickly scan log files, for example). Whe= n seems likely that every buffer will have its own value, I strongly believ= e it's cleaner to have the variable automatically buffer-local.

--00000000000091978605941909f5--