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, final testing Date: Sat, 01 Jul 2017 23:16:11 -0600 Message-ID: <87eftzju5g.fsf@lylat> References: <83y3s9pm2a.fsf@gnu.org> <87vandz7lw.fsf@lylat> <83wp7tpcav.fsf@gnu.org> <87r2y1z45o.fsf@lylat> <83vandp7wz.fsf@gnu.org> <87mv8pyy7f.fsf@lylat> <83shigpoxq.fsf@gnu.org> <87mv8nkh31.fsf@lylat> <83bmp3pnmb.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1498972636 27346 195.159.176.226 (2 Jul 2017 05:17:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 2 Jul 2017 05:17:16 +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 Sun Jul 02 07:17:10 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 1dRXFk-0006GT-Kg for ged-emacs-devel@m.gmane.org; Sun, 02 Jul 2017 07:17:00 +0200 Original-Received: from localhost ([::1]:56792 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dRXFo-0001J4-9C for ged-emacs-devel@m.gmane.org; Sun, 02 Jul 2017 01:17:04 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55153) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dRXFB-0001Ix-Sj for emacs-devel@gnu.org; Sun, 02 Jul 2017 01:16:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dRXF8-0008Os-Oo for emacs-devel@gnu.org; Sun, 02 Jul 2017 01:16:25 -0400 Original-Received: from mail-io0-x241.google.com ([2607:f8b0:4001:c06::241]:34610) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dRXF8-0008Oa-JA; Sun, 02 Jul 2017 01:16:22 -0400 Original-Received: by mail-io0-x241.google.com with SMTP id r70so353434ioe.1; Sat, 01 Jul 2017 22:16:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version; bh=5mtJ1EF74Mde3lr8zncQJ4HEWzGtgEahlCa9D5PvpVI=; b=rBmrJS+Yxd/BWub5qFaffeEeCJAx10f/wwostw7PV1C4RXNc57moTPkeBbMvNwQWQZ OZ2YVvSwCZ0fglMuC2ymTEhV9/k3vBTU0Cr6afxI91j5t76ACtPktZl12THodbOw2jKM ZCL5eIXOFpfvMEaEU1WYmYDHM9YUu/NEFXDneDMoqjHKFoe9KlWEpSRQ+akjpuP+Lu7P xH6RJ0R1FaP169IXkSNjYDFF+T5k9XDqZuwjC/aKeaM1kCLURXWmRh/dtBtcogKWpV3N e0Hz2CY5nubXEjp62rmUZjLa4PboNgOl9+UPQ1BQA+cG7uZFmBOFvMNnwiiG6QDeLXCR hhgw== 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:in-reply-to:references :user-agent:date:message-id:mime-version; bh=5mtJ1EF74Mde3lr8zncQJ4HEWzGtgEahlCa9D5PvpVI=; b=ExAbKG7qrZhQ5HoXacOZvvRgMkiAHG4UnVrlKPiwwsR66KWdNAaMPcjYTnZszoITlg teoJDnWxYccx25H1XnbKTMIsG/nXplXP+ezOXSab1Giyz7aQwBMZ0uvoTBUY1gYD8IMX aBFgu33ATW9SupvCeUTDbAJWFUyVU/Ux/0G6ZFibYapHuIb3myqF/+PLzVJcGLMLY0yU lxGh5AQjiiawgX0osdJqNfD0TaEno5RIyaoqKbAZ+ilh0CDivM2vt7Le+wRvIaTtN25u 12EvEG1afmJFPclHc4TWTl8lvbI3kAkXWjMuCp4bm+bWcMvta5inl2tnIuU0NClWszc5 CdZA== X-Gm-Message-State: AKS2vOzLN7cgV0pfYuVuvxuUTF6d8hdT3mpG9EPuZ42HwM8JJYwIAg0+ +8VbOjxWybCFLPcT X-Received: by 10.107.205.193 with SMTP id d184mr33701128iog.188.1498972581270; Sat, 01 Jul 2017 22:16:21 -0700 (PDT) Original-Received: from lylat (S010664777d9cebe3.ss.shawcable.net. [70.64.85.59]) by smtp.gmail.com with ESMTPSA id i5sm950443iti.20.2017.07.01.22.16.19 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 01 Jul 2017 22:16:20 -0700 (PDT) In-Reply-To: <83bmp3pnmb.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 02 Jul 2017 05:40:44 +0300") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4001:c06::241 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:216085 Archived-At: Eli Zaretskii writes: >> From: Alex >> Cc: emacs-devel@gnu.org >> Date: Sat, 01 Jul 2017 15:00:50 -0600 >> >> It's not intuitive to me why this occurs between lines with the same >> display line number width. If vertical-motion uses the same heuristic as >> display of line numbers, then why is the column changing between lines >> even when the width of line numbers isn't? > > Because vertical-motion thinks the display uses N+1 columns whereas it > actually uses only N. > >> Is it because it's using the heuristic with different inputs? > > Yes. The important input is the actual window-start point. > >> If so, can't they be modified to achieve the same results as the >> display of line numbers? > > I couldn't (yet) find a way of doing that. That's unfortunate; hopefully this can be fixed. >> Why is it necessary for line numbers to actually affect the vertical >> position of characters in the buffer? > > Because vertical-motion does its column calculation in pixels, C-n/C-p > need to adjust the calculations due to the pixels occupied by line > numbers. > >> I suppose it's a bit late to be asking this question, but the >> approach from an outside view feels odd. I don't know what the >> options were, but it's odd that line numbers aren't in their own >> special area like in (n)linum. Does the display engine not work well >> with margins? > > I firmly believe that line numbers should not be displayed on the > margins, because that produces problems for packages that want to > display stuff there. That seems to me to be an extensibility problem rather than line numbers not belonging in the margins. Without fixing that problem, then there will still be problems when multiple packages attempt to use the margins simultaneously. Can there not be multiple margins on one side? That way, line numbers can have its own special area, and there will be a clear x-coordinate for vertical-motion to start from, avoiding a whole class of errors that you've had to deal with so far. If not, why? That seems like a clear win to me, if it's possible. As a bonus, it would allow for users to customize the positions of elements in the margins (and fringes, hopefully).