From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Filipe Silva Newsgroups: gmane.emacs.help Subject: Re: relative line numbers and folding: how to make they play along? Date: Thu, 14 Jul 2016 12:55:48 -0300 Message-ID: References: <8360sbcvbz.fsf@gnu.org> <83lh158eza.fsf@gnu.org> <83bn208djh.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1468511802 11935 80.91.229.3 (14 Jul 2016 15:56:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 Jul 2016 15:56:42 +0000 (UTC) Cc: help-gnu-emacs@gnu.org To: Eli Zaretskii Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Jul 14 17:56:40 2016 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bNj07-0001q0-QQ for geh-help-gnu-emacs@m.gmane.org; Thu, 14 Jul 2016 17:56:36 +0200 Original-Received: from localhost ([::1]:55155 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNj07-0004KL-2e for geh-help-gnu-emacs@m.gmane.org; Thu, 14 Jul 2016 11:56:35 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38811) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNizT-0004Hv-Sg for help-gnu-emacs@gnu.org; Thu, 14 Jul 2016 11:55:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bNizR-0001OA-V3 for help-gnu-emacs@gnu.org; Thu, 14 Jul 2016 11:55:55 -0400 Original-Received: from mail-oi0-x236.google.com ([2607:f8b0:4003:c06::236]:36184) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNizP-0001NU-1g; Thu, 14 Jul 2016 11:55:51 -0400 Original-Received: by mail-oi0-x236.google.com with SMTP id w18so123644866oiw.3; Thu, 14 Jul 2016 08:55:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IL+kR3ODIGJFbgmfZhxcSEzdeIjfjOcn+qct/S3N7Gs=; b=ipGp3wkESJ24Fle3bgErMXCZfZ1AiHCb9h9vL+Exd1mYDmMIMJZg+CXp0GOlC/9HCO VMURyRPJzC0z7eYlRma0DhjjPXJuglmqM6pjt6xJBigfvugyRma3RlkjB2pxyvA0RvoM HUgTMMcIYpCLICwlSiMf3Z7L7oHxH5x8QGaJ/SaxVVvWuiR6U0V3/vB+TWcLRCgxinlP OhUUKMzIv14FasMTgTzdQITU0zHhsQ89QJzaKuOf8KmIdfGJABs5W5/RGTar+hH2qx8r 9g5+nYqJVxv0DggP1YQhltMvksyJqmnXke64sgEw1dLLsv0pzXkOaE+wQY7y7iM+JDKg HUvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IL+kR3ODIGJFbgmfZhxcSEzdeIjfjOcn+qct/S3N7Gs=; b=F+8mWn7WzG8DbwixV7MGBrp2zPhC+saUFc1B8TExCZiNfFBX8sV43qtjoQJCTb8jGV Zr+EIb52vAlesvJc+NdOJxQUspxEvn2pIJhA0mY1gxDnNL/6dGZ0owdaY0UN7afNjcpe 5f6pM2eUFwFUon7CqbzkQghpxqR6ddVtUtIO6lE/OLYTYuAHkQFvQVUKF30pKBdkjGvT EqKkwFBIsn94Jvkr05bauSVrM1PUbJSmMFvjIeEdXHbgLwlVm7rqj+ZFWFbusFkzm2uH y70JORY+nEnfmpkpz4RNQua3mPaPR56+tGh68sl4CHcVMYuGsiW87wg8vetqWraK6Tve orTg== X-Gm-Message-State: ALyK8tKmcIsklpFkK0HiSoj491IuhL8+f6Skqh+Qa9PMd+i4X8OclEcanlOGTYnyMOMzH5V2PP7q4YzuqftLqg== X-Received: by 10.157.48.106 with SMTP id w39mr9912287otd.108.1468511749778; Thu, 14 Jul 2016 08:55:49 -0700 (PDT) Original-Received: by 10.202.114.196 with HTTP; Thu, 14 Jul 2016 08:55:48 -0700 (PDT) In-Reply-To: <83bn208djh.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:4003:c06::236 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:110841 Archived-At: Dan Spen wrote: > Your example shows 2 buffers in "markdown mode" sorry, I don't have that > installed. Oddly both examples have 2 line 1s, one with indentation. I > can't tell what's going on there with your "relative" line numbers so I > have to assume line 1 is somehow ignored by Emacs and treated as a > hierarchical value in vim. Hi dan, thanks for taking the time to think about this feature request. Yes the one with indentation is vim. It's indented to highlight that this is the current line. But I'd rather have it not indented. highlighting the current line number with a proper colouring would be enough and would save precious screen space. And it's not hierarchical by any means. It's just a cue to help showing on what line the cursor is. Dan Spen wrote: > ie. in vim, the 4j command goes to line 1.4. > Seems pretty illogical, so I think you should explain those first lines. It's logical, actually. See, in vim you have commands to move to absolute lines and to move to lines relative to where you are. So if you want really to go to the absolute line 234 of the file, you have the command `gg`. So `234gg` will take you there. Now `j`, moves point to the line imediatelly below to where point is now. But it accepts an argument. So `9j` moves point 9 lines below to where point current is. Makes sense? Now that's very interesting. Suppose you have a section of the file displayed now on your screen. point is somewhere on this screen. And you're seeing a line of interest 17 lines below the line to where you are. If you know that, if you have that information available, you can simply type `17j` and you're already there. Makes for a very simple, lightweight, precise and fast way of navigating vertically on your *current display*. Now I'm sure that emacs has the same operation that would take me up/down relative to point, accepting the argument. If we could have relative line numbers, that'd be a breeze. We could have even a toggle mechanism available in linum-mode. Here, I have created a new example that I think will clarify the argument: https://gist.github.com/ninrod/6ac5c0ea9b68c6d116e9cb0509dbe796 Dan Spen wrote: > Emacs appears to be doing the right thing as far as showing you line > numbers if you make the logical assumption that the displayed line > numbers are the original line numbers, possibly in the original file. > (Assuming the buffer represents a file.) Well Dan, with the above explanation, now I think it became clear that if I want to have the absolute line numbers displayed, the logical thing to do would be to use the stock linum-mode. If I want to use a relative line number mode, the last thing that I want to have displayed are the absolute line numbers. Makes sense? Dan spen wrote: > So, you appear to want the illogical option, Ie, the line numbers > displayed are relative to the display line, not the file. > Of course Emacs jump commands (M-g g for example) would have to > be changed to operate on those numbers. (More on that below.) Well I hope that with the explanation above, you saw the logic behind the feature request. Dan spen wrote: > So, the problem seems to be that 4j is harder to type than 12j or some > other larger number. Actually, `4j` is easier to type than `567gg`. That's part of the problem. Another benefit: `4j` is a movement while `567gg` is a jump. So `d4j` deletes from point to 4 lines below point. `y4j` yanks the line where point is to 4 lines below where point is. The list goes on. Makes for very precise and fast text operations. You may be thinking why I'm talking about vim features if this is an emacs list. Well the thing is that emacs is so powerful that people created a mode that almost completely emulates vim visual editing operations and quite a bit of ex commands too. And people are starting to migrating to emacs *en masse* to have the vim keybindings plus all the power that emacs brings with it's extensive architecture, elisp powerful mode like orgmode and async features. Dan spen > A feature that no sane person would use? You've got me. I'm a sane person, but only when I'm not talking to Emocs and vimmie, the two creatures that ocasionally sit on my shoulders. (vimmie is the evil one) On Thu, Jul 14, 2016 at 12:06 PM, Eli Zaretskii wrote: > > From: Stefan Monnier > > Date: Wed, 13 Jul 2016 22:36:49 -0400 > > > > >> I think to implement relative-visual-linum-mode efficiently, we'd need > > >> help from the display engine. E.g.: > > >> - First perform redisplay of the window. > > >> - then, go through the window, visual-line by visual-line > > >> and add something in the margin. > > >> - then update the margin part of the matrices. > > > > > AFAIU, this would cause a momentary flickering of an incorrect display > > > (without the line numbers), until they are computed and displayed. > > > > Actually, I don't think there needs to be flickering if the first step > > ("perform redisplay of window") just computes the new matrices without > > performing any drawing. > > Since the display engine computes the number of each screen line as it > lays them out, I don't understand why would 2 phases be needed. I'm > probably missing something. > > > > And I still don't see any answer to my question, alas. > > > > It's basically: linum-mode but where the line numbers are relative to > > `point` rather than counting from `point-min`, and additionally it > > should count visual lines (so 10 invisible lines of text don't affect > > the line numbers of the text that is displayed). > > So some lines will have negative numbers? And they change whenever > point moves into a different line? And when the window is scrolled, > the numbers also change? > >