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

[Dan Espen]

Filipe Silva <filipe.silva@gmail.com> writes:

> On Wed, Jul 13, 2016 at 5:23 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> > From: Stefan Monnier <monnier@iro.umontreal.ca> Date: Wed, 13 Jul
>> > 2016 16:10:30 -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.
>>
>> And I still don't see any answer to my question, alas.

Please don't top post.

> Eli, sorry, I did not answer your question because everybody on other
> forums, github, etc... told me that I would need to install a third
> party package to do what I showed and even them, it would not play
> along with folding.
>
> So I wanted to know if you could, starting from emacs -Q, construct a
> lisp code that achieved the effect shown here:
>
> https://cloud.githubusercontent.com/assets/8352747/16707876/4bd64c22-45b5-11e6-8d13-ae9c994cbb02.png

I'm going to try to make sense of your description of
"relative line numbers" and the utility of such a feature.

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.  ie. in vim, the 4j command goes to line 1.4.  
Seems pretty illogical, so I think you should explain those first lines.

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.)

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.)

I'm going to guess that you want subsequent screens to always start with
relative  line numbers.   Then you  would need  Emacs to  look over  all
previous lines then discount anything that would be hidden.

Sounds like a mis-feature to me, but there are lots of line-number
modes:

https://www.emacswiki.org/emacs/LineNumbers

None of them seem to do what you ask, giving evidence that this would be
a mis-feature.

Regarding the discussion at:

https://github.com/syl20bnr/spacemacs/issues/6536

  Suppose I want to jump to function user-config in the screenshot
  above. A simple 4j would suffice. But I don't know that because
  spacemacs is saying that the line I want is 194 lines below the
  current line, which would be true if the file had no folding on. With
  folding on, it is not true anymore.

  So folding is rendering relative line numbers unusable at the present
  moment.

So, the problem seems  to be that 4j is harder to type  than 12j or some
other larger number.  Of course, I'm guessing that your requirement is
such that sometimes each method would have large numbers.  If so,
this change would only be marginally useful.
A more logical requirement would be to start line numbers from 1 on
every screen giving very small numbers to jump to regardless of file
size.

Lastly, I'm using GNUS.  I thought I would turn on line numbers
in the buffer for this message.  I did M-x linum-mode. That works fine,
all visible lines are numbered sequentially.

Then I tried a few variations on the Emacs jump command M-g g.
Oddly enough, M-g g 1 thru 7 go to line 1.
M-g g 8 goes to line 2.  So, looks like Message mode has some sort
of hidden lines that operate close to the way you request.

I have no idea what's going on there.

> If it can't be done, I think it is the case to issue a feature request
> for that.

A feature that no sane person would use?

-- 
Dan Espen