From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alex Newsgroups: gmane.emacs.devel Subject: Re: Native line numbers landed on master Date: Mon, 10 Jul 2017 14:31:46 -0600 Message-ID: <87a84crq31.fsf@lylat> References: <83k23jl5ra.fsf@gnu.org> <87r2xqo8p7.fsf@lylat> <83lgnxk7v6.fsf@gnu.org> <87shi5jk2w.fsf@lylat> <83lgnwi3k3.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1499718789 8326 195.159.176.226 (10 Jul 2017 20:33:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 10 Jul 2017 20:33:09 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 10 22:33:04 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 1dUfMY-0001YB-PB for ged-emacs-devel@m.gmane.org; Mon, 10 Jul 2017 22:32:58 +0200 Original-Received: from localhost ([::1]:42938 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dUfMe-00065c-2b for ged-emacs-devel@m.gmane.org; Mon, 10 Jul 2017 16:33:04 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59931) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dUfMX-00065L-HM for emacs-devel@gnu.org; Mon, 10 Jul 2017 16:32:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dUfMT-0006Nc-K9 for emacs-devel@gnu.org; Mon, 10 Jul 2017 16:32:57 -0400 Original-Received: from mail-it0-f47.google.com ([209.85.214.47]:35178) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dUfMT-0006NK-FM; Mon, 10 Jul 2017 16:32:53 -0400 Original-Received: by mail-it0-f47.google.com with SMTP id v202so44821003itb.0; Mon, 10 Jul 2017 13:32:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=bbDSSckT5egPhoQI8wwLGIfgjEI5qXXKoTxQKj+dMAQ=; b=NLUrUN28HKNgeFMdb8sPX7G6N/pBkNCqZAvM/VuLhWHqUxPHku5eiJac23ULfC9eKx LH8Kx/ufADIbChzi3OFs2UK6MA11KZ2ZI2Juxx5Ma3D/i5YeFDz3IYoeURYSV2PpQGgc GxBvqB9UNoZrycc+MyAueIY0j01QzywK7dLTzNZaJhdTisYaH0TS+t5fFOM7nHAxiwpr 6qBdOAqcn2n/xPrts36rcoj7Hfn54FTJnA6qLv6KIkBj4SpAeLYoHx+jnI5Zl2PI9uxm H0p4zHtBfr3PLF8YXRqxVQbP2psSL6M0Mn/1YeJ0v8tqLMo/dbXzz8pIuoRaDzKj9I13 L0sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=bbDSSckT5egPhoQI8wwLGIfgjEI5qXXKoTxQKj+dMAQ=; b=brkUx6wmv3wdKpR1jNAdxrvBRea0Kwqfl6/nias0yz6WMQCiQq48kz/jb6AWZPM7yx dLLTAes8AFsKiGsinKr12y21KO9NjseMk7audukOWBxbCFR6nC3nWQ0HKWIzjYBJBI/0 ytifMazF9nczXOPgm43rTqImqzLFCscJSe1m+HWz1Q8O2AYvh+82euY+hC4t52zi9p4x s3GC1YXf0/Ytnhit7xpiAl8zCUJ9gSPY93q8e5FSdMJuSyjs1ygQt98Smbq5iZQEX812 emdgffElTROXWEpcSEsdsMNnWRPfimCASxxET8ckGLWMLodKWDqjiNG4/8aq0Ewl3bi6 JsHQ== X-Gm-Message-State: AIVw112p/D3ldZL0x3e/OZ6zqb52DO4O16+X0ybFF/V3IcC84xz98JS1 liaS1cU52ln6Z3Sb X-Received: by 10.36.10.16 with SMTP id 16mr92747itw.7.1499718712316; Mon, 10 Jul 2017 13:31:52 -0700 (PDT) Original-Received: from lylat (S010664777d9cebe3.ss.shawcable.net. [70.64.85.59]) by smtp.gmail.com with ESMTPSA id e77sm4461766itd.18.2017.07.10.13.31.50 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 10 Jul 2017 13:31:51 -0700 (PDT) In-Reply-To: <83lgnwi3k3.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 10 Jul 2017 20:50:52 +0300") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.85.214.47 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:216440 Archived-At: Eli Zaretskii writes: >> From: Alex >> Cc: emacs-devel@gnu.org >> Date: Sun, 09 Jul 2017 16:56:23 -0600 >> >> I've attached a patch below. I changed the menu bar to toggle the global >> mode since the other toggles in the Show/Hide menu are also toggled >> globally. Does it look alright for inclusion? > > I have some comments: > >> +(defgroup display-line-numbers nil >> + "Display line numbers in the buffer." >> + :group 'display) > > This means the defcustoms here will be separate from those defined in > cus-start.el. Is that intended? > > More generally, do we want some of the defcustoms to live here and > some in another file? And if we want all of them here, does that mean > this file needs to be preloaded, or at least auto-loaded when > display-line-numbers is set by the user? 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? I don't know if the file should be pre/auto-loaded. Is there a reason to do so considering linum.el isn't? >> +(define-globalized-minor-mode global-display-line-numbers-mode >> + display-line-numbers-mode >> + (lambda () >> + (unless (or (minibufferp) >> + ;; taken from linum.el >> + (and (daemonp) (null (frame-parameter nil 'client)))) >> + (display-line-numbers-mode)))) > > The daemonp part is only needed when display-line-number-width-start > is non-nil, right? I suppose so, but would one want line numbers in that specific buffer either way? I added that part because you added it to linum.el in bd3c6eec. Does the problem affect display-line-numbers? Also, I was wondering if setting display-line-number-width in pre-command-hook unconditionally is a good idea. I timed it and the function itself seemed slightly faster than a let/when approach, but describe-variable states that setting it calls set-buffer-redisplay, which disables redisplay optimizations. So if I understand this correctly, adding the current display-line-numbers-update-width to pre-command-hook would disable redisplay optimizations for every command. 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.