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

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

[Filipe Silva]

Hi good people,

there was some discussion in spacemacs about the relative line number
behaviour in emacs:
https://github.com/syl20bnr/spacemacs/issues/6536

In essence, currently relative line numbers in emacs are rendered useless
if folding is applied to the buffer.
Here's a nice example: left is emacs, right is vim:

https://cloud.githubusercontent.com/assets/8352747/16707876/4bd64c22-45b5-11e6-8d13-ae9c994cbb02.png

One of the spacemacs maintainers specifically said: "I should note that due
to how folding and line numbers work in Emacs this would be nigh impossible
to fix."
I find that difficult to believe given how people in emacs community praise
about emacs infinite extensibility.

So I ask you, do we have tools to fix this behaviour or do we need a patch
in emacs itself?

Thanks in advance,

Filipe Silva

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

[Eli Zaretskii]

> From: Filipe Silva <filipe.silva@gmail.com>
> Date: Mon, 11 Jul 2016 12:11:45 -0300
> 
> there was some discussion in spacemacs about the relative line number
> behaviour in emacs:
> https://github.com/syl20bnr/spacemacs/issues/6536
> 
> In essence, currently relative line numbers in emacs are rendered useless
> if folding is applied to the buffer.

What are "relative line numbers" in Emacs?  I see nothing in these
discussions that describes how (with what commands/packages) the line
numbers were produced in Emacs.  So it's hard to tell anything
intelligent about this issue.

> One of the spacemacs maintainers specifically said: "I should note that due
> to how folding and line numbers work in Emacs this would be nigh impossible
> to fix."
> I find that difficult to believe given how people in emacs community praise
> about emacs infinite extensibility.

The right place and way to discuss this is by filing a bug report with
all the specifics, including a recipe for reproducing the issue,
preferably starting from "emacs -Q".

Thanks in advance.

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

[Filipe Silva]

Is there a way, from emacs -Q, of setting relative line numbers as shown
here?

https://cloud.githubusercontent.com/assets/8352747/16707876/4bd64c22-45b5-11e6-8d13-ae9c994cbb02.png





On Tue, Jul 12, 2016 at 1:51 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Filipe Silva <filipe.silva@gmail.com>
> > Date: Mon, 11 Jul 2016 12:11:45 -0300
> >
> > there was some discussion in spacemacs about the relative line number
> > behaviour in emacs:
> > https://github.com/syl20bnr/spacemacs/issues/6536
> >
> > In essence, currently relative line numbers in emacs are rendered useless
> > if folding is applied to the buffer.
>
> What are "relative line numbers" in Emacs?  I see nothing in these
> discussions that describes how (with what commands/packages) the line
> numbers were produced in Emacs.  So it's hard to tell anything
> intelligent about this issue.
>
> > One of the spacemacs maintainers specifically said: "I should note that
> due
> > to how folding and line numbers work in Emacs this would be nigh
> impossible
> > to fix."
> > I find that difficult to believe given how people in emacs community
> praise
> > about emacs infinite extensibility.
>
> The right place and way to discuss this is by filing a bug report with
> all the specifics, including a recipe for reproducing the issue,
> preferably starting from "emacs -Q".
>
> Thanks in advance.
>
>

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

[Stefan Monnier]

> What are "relative line numbers" in Emacs?  I see nothing in these
> discussions that describes how (with what commands/packages) the line
> numbers were produced in Emacs.  So it's hard to tell anything
> intelligent about this issue.

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.


        Stefan

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

[Eli Zaretskii]

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

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

[Filipe Silva]

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

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

cheers,

Filipe

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

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

[Eli Zaretskii]

> From: Filipe Silva <filipe.silva@gmail.com>
> Date: Wed, 13 Jul 2016 19:33:34 -0300
> Cc: help-gnu-emacs@gnu.org
> 
> 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

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?

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

A feature request will have to describe the desired feature, so what
I'm asking is needed for that as well.

Thanks.

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

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

[Stefan Monnier]

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

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


        Stefan

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

[Eli Zaretskii]

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

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

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

[Filipe Silva]

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

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

[Eli Zaretskii]

> From: Filipe Silva <filipe.silva@gmail.com>
> Date: Thu, 14 Jul 2016 12:58:20 -0300
> Cc: help-gnu-emacs@gnu.org
> 
> "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. 

Perhaps something like a post-command-hook that measures line numbers
with vertical-motion, and then sets up the corresponding numbers on
the margin, like linum-mode does, could do this.

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

[Filipe Silva]

Great Eli. Does that post-command-hook exist today in stock emacs?

Do you agree with the usefulness of the feature?

On Thu, Jul 14, 2016 at 1:12 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Filipe Silva <filipe.silva@gmail.com>
> > Date: Thu, 14 Jul 2016 12:58:20 -0300
> > Cc: help-gnu-emacs@gnu.org
> >
> > "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.
>
> Perhaps something like a post-command-hook that measures line numbers
> with vertical-motion, and then sets up the corresponding numbers on
> the margin, like linum-mode does, could do this.
>
>

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

[Boris]

Hey Filipe,

`post-command-hook` exists today and you can verify it by calling `C-h v
post-command-hook`.

~ d12frosted

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

> Great Eli. Does that post-command-hook exist today in stock emacs?
>
> Do you agree with the usefulness of the feature?
>
> On Thu, Jul 14, 2016 at 1:12 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>
> > > From: Filipe Silva <filipe.silva@gmail.com>
> > > Date: Thu, 14 Jul 2016 12:58:20 -0300
> > > Cc: help-gnu-emacs@gnu.org
> > >
> > > "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.
> >
> > Perhaps something like a post-command-hook that measures line numbers
> > with vertical-motion, and then sets up the corresponding numbers on
> > the margin, like linum-mode does, could do this.
> >
> >
>

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

[Stefan Monnier]

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

If we bake it into the redisplay code, we can indeed do it "on the fly",
but if we want this feature to be implemented in Elisp it seems a lot
more tricky to avoid the 2 passes.

> So some lines will have negative numbers?

Right.

> And they change whenever point moves into a different line?

Right.  And they're different for different windows displaying the
same buffer.

> And when the window is scrolled, the numbers also change?

Well, to the extent that point probably changes when the window is
scrolled, yes.  Otherwise not necessarily.


        Stefan

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

[Filipe Silva]

Great news gentleman! That'd be a nice little adition to emacs!

On Thu, Jul 14, 2016 at 6:03 PM, Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> >> 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.
>
> If we bake it into the redisplay code, we can indeed do it "on the fly",
> but if we want this feature to be implemented in Elisp it seems a lot
> more tricky to avoid the 2 passes.
>
> > So some lines will have negative numbers?
>
> Right.
>
> > And they change whenever point moves into a different line?
>
> Right.  And they're different for different windows displaying the
> same buffer.
>
> > And when the window is scrolled, the numbers also change?
>
> Well, to the extent that point probably changes when the window is
> scrolled, yes.  Otherwise not necessarily.
>
>
>         Stefan
>
>
>

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

[Stefan Monnier]

> Great news gentleman!

You probably misread.


        Stefan

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

[Filipe]

No, I'm just happy it can be done. I know you haven't settled yet on implementing it.

On 14 de jul de 2016, at 21:18, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>> Great news gentleman!
> 
> You probably misread.
> 
> 
>        Stefan
> 
> 

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 14 Jul 2016 17:03:07 -0400
> 
> >> 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.
> 
> If we bake it into the redisplay code, we can indeed do it "on the fly",
> but if we want this feature to be implemented in Elisp it seems a lot
> more tricky to avoid the 2 passes.

But this sub-thread started with you talking about baking it into
redisplay:

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

These two passes are described in terms of what redisplay does, they
are not visible to Lisp: we don't return to the command loop after
each window's redisplay, and the glyph matrices are not exposed to
Lisp, either.

So now I'm confused about what you are suggesting.

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

[Stefan Monnier]

>> >> 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.
>> If we bake it into the redisplay code, we can indeed do it "on the fly",
>> but if we want this feature to be implemented in Elisp it seems a lot
>> more tricky to avoid the 2 passes.
> But this sub-thread started with you talking about baking it into
> redisplay:

By "help from the display engine" I meant that we'd need to make
changes to the C code, but I didn't mean to bake it in.

> These two passes are described in terms of what redisplay does, they
> are not visible to Lisp: we don't return to the command loop after
> each window's redisplay, and the glyph matrices are not exposed to
> Lisp, either.

I didn't mean to return to the command-loop in-between.

I was more thinking of the situation I mentioned in some other
discussion: rewrite the top-level of the redisplay code in Elisp,
basically a function which:
- asks the C code which windows need to be redisplayed.
- call a C function on each of those windows to recompute the matrices.
- detect the case where point is out of the window, and either move
  point and call the recompute-matrices function, or call another
  C function to do the scrolling.
- then call a C function on each window/frame to update the display.

From there we can hope to provide a more efficient/robust follow-mode
(while still implementing it in Elisp).  And in that context, we should
also be able to provide a more efficient relative-visual-linum-mode, tho
it might require yet more access, such as subrs to scan/read the
matrices, and maybe other subrs to modify the matrices (to update the
margin).

Some of those primitives would probably also be useful in order to write
tests of the redisplay code.

I think such a change should be doable without a complete rewrite of
the redisplay.  But it would undoubtedly take a fair bit of work.


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 15 Jul 2016 09:53:44 -0400
> 
> I was more thinking of the situation I mentioned in some other
> discussion: rewrite the top-level of the redisplay code in Elisp,

Conditioning the minor feature discussed in this thread on such a
thorough rewrite of the display code sounds like overkill to me.

> basically a function which:
> - asks the C code which windows need to be redisplayed.
> - call a C function on each of those windows to recompute the matrices.
> - detect the case where point is out of the window, and either move
>   point and call the recompute-matrices function, or call another
>   C function to do the scrolling.
> - then call a C function on each window/frame to update the display.
> 
> >From there we can hope to provide a more efficient/robust follow-mode
> (while still implementing it in Elisp).  And in that context, we should
> also be able to provide a more efficient relative-visual-linum-mode, tho
> it might require yet more access, such as subrs to scan/read the
> matrices, and maybe other subrs to modify the matrices (to update the
> margin).
> 
> Some of those primitives would probably also be useful in order to write
> tests of the redisplay code.
> 
> I think such a change should be doable without a complete rewrite of
> the redisplay.  But it would undoubtedly take a fair bit of work.

Frankly, I don't see any significant gains in your suggestion.
Basically, you suggest to leave the bulk of the display code
unchanged, and introduce a Lisp-level driver that calls its parts one
after the other.  Moreover, that Lisp will be called from C, since
that's where we currently invoke redisplay.  I don't see why we would
want that, and disagree with you that this will make the job of
follow-mode easier (because what follow-mode wants is intervene in the
middle of some of those parts you want to leave in C).

I think a much better plan is to expose some of the C data structures
to Lisp, and provide focused hooks at strategic places for Lisp to be
able to affect what redisplay does, by accessing those data structures
and making decisions based on that.

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

[Stefan Monnier]

>> I was more thinking of the situation I mentioned in some other
>> discussion: rewrite the top-level of the redisplay code in Elisp,
> Conditioning the minor feature discussed in this thread on such a
> thorough rewrite of the display code sounds like overkill to me.

There's no conditioning at play here.  I was only discussing how to make
it reasonably efficient.

> Frankly, I don't see any significant gains in your suggestion.
> Basically, you suggest to leave the bulk of the display code
> unchanged, and introduce a Lisp-level driver that calls its parts one
> after the other.

That's right.  The idea being to try and keep as much of the existing
code as possible.

> I think a much better plan is to expose some of the C data structures
> to Lisp, and provide focused hooks at strategic places for Lisp to be
> able to affect what redisplay does, by accessing those data structures
> and making decisions based on that.

I think my plan fits this description.  But other plans would too,


        Stefan

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

[Filipe Silva]

Maybe this new display mechanism would be useful and would open up other
possibilities. Maybe there benefits there that are not enclosed only to
enabling an efficient relative line number implementation. It could create
new types of modes or simplify the implementation of existing ones? Just a
thought.

On Fri, Jul 15, 2016 at 11:54 AM, Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> >> I was more thinking of the situation I mentioned in some other
> >> discussion: rewrite the top-level of the redisplay code in Elisp,
> > Conditioning the minor feature discussed in this thread on such a
> > thorough rewrite of the display code sounds like overkill to me.
>
> There's no conditioning at play here.  I was only discussing how to make
> it reasonably efficient.
>
> > Frankly, I don't see any significant gains in your suggestion.
> > Basically, you suggest to leave the bulk of the display code
> > unchanged, and introduce a Lisp-level driver that calls its parts one
> > after the other.
>
> That's right.  The idea being to try and keep as much of the existing
> code as possible.
>
> > I think a much better plan is to expose some of the C data structures
> > to Lisp, and provide focused hooks at strategic places for Lisp to be
> > able to affect what redisplay does, by accessing those data structures
> > and making decisions based on that.
>
> I think my plan fits this description.  But other plans would too,
>
>
>         Stefan
>
>
>

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

[Dan Espen]

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

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

Oh, I see now.  I'm not a vim user, so I completely missed that
j is the command to move down a line.

> 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

Okay, now I understand what you want.
Some way of knowing how many lines you want to move or delete or copy
from the current line.

I don't see how that would be a problem for Emacs at all.
Emacs would simply start from the line with point, show it's line
number, then the rest of the screen wouldn't show line numbers, instead
just it's screen offset from the line with point.

I don't know enough about Emacs to say where or when that would be done
but it looks simple.

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

It does now.

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

Obviously my comment about "sane" was based on not understanding
what you wanted.

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

Seems like this reply is mangled...

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

-- 
Dan Espen

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

[Rusi]

On Thursday, July 14, 2016 at 8:07:07 AM UTC+5:30, Stefan Monnier wrote:
> > 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).
> 

Thanks for that Stefan!

Specifically on this request
Also more generally: Glad to see that the more knowledgeable people are also 
more respectful.

PS Any reason you keep your mail options set to cut off names of people you are responding to?  Makes it hard for subsequent responses...

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

[Stefan Monnier]

> PS Any reason you keep your mail options set to cut off names of people you
> are responding to?

Yes: my answers are to the argument/info in the text, not to the person
who wrote them.


        Stefan