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

[Filipe Silva <filipe.silva@gmail.com>]

Eli Zaretskii wrote:

"Problem is, I don't really understand what's the desired effect shown
there, exactly.  That's why I asked to explain what do you mean by
"relative line numbers".  Does that mean "count lines that will be
displayed, skipping the invisible ones"?  Or does it mean "count lines
shown in a window, where the first visible line in the window is
always line 1"?  Or does it mean something else?"

Eli, thanks. I think now I have described the feature with more clarity in
my responde to Dan (I think). If it is not clear yet, please let me now.

On Thu, Jul 14, 2016 at 12:55 PM, Filipe Silva <filipe.silva@gmail.com>
wrote:

> 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?
>>
>>
>