Re: relative line numbers and folding: how to make they play along?

[Filipe Silva]

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 <eliz@gnu.org> wrote:

> > From: Stefan Monnier <monnier@iro.umontreal.ca>
> > 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?
>
>