Native display of line numbers

Native display of line numbers

[Eli Zaretskii]

I generally consider display of line numbers for each line in the
buffer un-Emacsy, something that came from the dark era when we needed
to count lines to be able to tell the then existing editors something
like "move down N lines, then DO SOMETHING".  Emacs pioneered today's
world where all this is unnecessary, and the rest is history.

However, many users want line numbers to be displayed in Emacs.  I
don't know why they want it, perhaps they were "spoiled" by other IDEs
or something.  In any case, given the popularity of the various add-on
modes which insist on displaying line numbers using all kinds of
tricks, I don't think we can ignore this tendency any longer, even if
we agree that this is a disease.  The "epidemic" has spread too far
and too wide for us to continue looking the other way.  And since
Emacs doesn't make it easy for a Lisp program to invade the holy realm
of redisplay, those modes use tricks that make Emacs slower and
frequently interfere with other packages.  They also make demands on
the display engine that make Emacs harder to develop and maintain.

So with that in mind, I came up with an implementation of a native
display of line numbers.  You can find it in the scratch/line-numbers
branch of the Emacs repository.  Compared with linum-mode,
nlinum-mode, and other similar modes, it has the following main
advantages:

  . it works significantly faster (almost twice as fast as linum-mode,
    50% faster that relative-line-numbers-mode)
  . it doesn't use the display margins
  . it works with R2L text, something the old modes never did

The main features of the line-numbering modes are all supported by
this new feature.

Please give it a try and report any bugs you find.  I'm sure there
will be quite a few bugs, given the sheer amount of display feature
which could be affected, and which I didn't have time to test.

Once the flood of serious bug reports dries out, I will look into
merging this to master.  If, miraculously, no such flood arrives, I
will merge in a couple of weeks.  When that happens, we will declare
all the other modes which do the same job deprecated.

TIA

Re: Native display of line numbers

[Stefan Monnier]

> So with that in mind, I came up with an implementation of a native
> display of line numbers.

Cool!

>   . it works significantly faster (almost twice as fast as linum-mode,
>     50% faster that relative-line-numbers-mode)

Should I read this to me that the speed difference w.r.t nlinum is not
that large, or you didn't bother comparing?  (I think nlinum's
performance is pretty good (well, as long as the number of overlays doesn't
get in the way, as long as you don't try to push it towards
relative-line-number, as long as you don't enable the new
nlinum-highlight-current-line which currently has a performance bug,
...)).

>   . it works with R2L text, something the old modes never did

I didn't know there were problems with R2L text.  Worse: even now that
you tell me, I can't think of nor find a problem with it (other than the
choice of whether to display the line numbers in the left or right
margin).

I'm curious what these issues are (or were, since your code will
presumably make these limitations irrelevant).


        Stefan

Re: Native display of line numbers

[Kaushal Modi]

[-- Attachment #1.1: Type: text/plain, Size: 2544 bytes --]

Hi Eli,

First of all, thank you for working on this!

On Sat, Jun 17, 2017 at 11:12 AM Eli Zaretskii <eliz@gnu.org> wrote:

> I generally consider display of line numbers for each line in the
> buffer un-Emacsy, something that came from the dark era when we needed
> to count lines to be able to tell the then existing editors something
> like "move down N lines, then DO SOMETHING".  Emacs pioneered today's
> world where all this is unnecessary, and the rest is history.
>

While I don't use the line numbers that way, it's very useful to pinpoint a
colleague directly to a piece of code, especially when not sharing the code
visually; like when over a phone call: "Hey, open up the "foo" file and
look at line 1534.". Nothing beats the precision of that.


> However, many users want line numbers to be displayed in Emacs.  I
> don't know why they want it, perhaps they were "spoiled" by other IDEs
> or something.


Above.


> So with that in mind, I came up with an implementation of a native
> display of line numbers.  You can find it in the scratch/line-numbers
> branch of the Emacs repository.


Thanks!


> Compared with linum-mode,
> nlinum-mode, and other similar modes, it has the following main
> advantages:
>
>   . it works significantly faster (almost twice as fast as linum-mode,
>     50% faster that relative-line-numbers-mode)
>

How does it compare to nlinum.el in your initial testing? I will also test
it out over next few days.


> Please give it a try and report any bugs you find.
>

Here's my first observation after building from that branch.

In the below image, on the left I have emacs -Q running that has the new
line number feature enabled, and on the right I have older emacs instance
running with nlinum.el enabled.

[image: image.png]
Can you please add support for highlighting the current line number, using
a different face (See the highlighted line number by nlinum on the right
hand side)?

About the code:

+(defun toggle-display-line-numbers ()
+ (interactive)
+ (if display-line-numbers
+ (setq display-line-numbers nil)
+ (setq display-line-numbers t))
+ (force-mode-line-update))

Instead of this, about about a minor mode with an intuitive name like
"line-numbers-mode"? Above also has an issue, I believe.. If user has set
display-line-numbers to 'relative, toggling it will always set it back to t.

How about leaving the buffer local display-line-numbers definition as it
is, but replacing toggle-display-line-numbers function with a minor mode
line-numbers-mode?

Thanks!
-- 

Kaushal Modi

[-- Attachment #1.2: Type: text/html, Size: 4676 bytes --]

[-- Attachment #2: image.png --]
[-- Type: image/png, Size: 249811 bytes --]

Re: Native display of line numbers

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 609 bytes --]

On Sat, Jun 17, 2017, 12:52 PM Kaushal Modi <kaushal.modi@gmail.com> wrote:

>
> but replacing toggle-display-line-numbers function with a minor mode
> line-numbers-mode?
>

Of course the line-number-mode to toggle line numbers in just the mode line
already exists.

Can the same minor mode be reused? Then using a defcustom user can specify:

- line numbers in the margin (what would be the right word for that?), mode
line or both
- line numbers in the 'margin': regular/relative
- line numbers in the 'margin': current line highlight on/off (my requested
feature in the previous email)

> --

Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 1316 bytes --]

Re: Native display of line numbers

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Sat, 17 Jun 2017 16:52:11 +0000
> 
>  . it works significantly faster (almost twice as fast as linum-mode,
>  50% faster that relative-line-numbers-mode)
> 
> How does it compare to nlinum.el in your initial testing? I will also test it out over next few days.

nlinum performed so poorly in my benchmarks that I was ashamed of
publishing the data.  The benchmark entails scrolling through xdisp.c
one line at a time.  The code is at the end of this message (it was
posted by Dmitry Antipov), you can try it yourself.  The first run is
always slow because Emacs fontifies on the fly, so I timed only the
second run.

> Can you please add support for highlighting the current line number, using a different face (See the highlighted
> line number by nlinum on the right hand side)?

Is it really important?  Why? do people really have difficulty finding
the line where point/cursor is?

I could add this feature if it's deemed important, but it will slow
down redisplay to some extent, because cursor motion can no longer be
considered affecting the cursor alone.

> About the code:
> 
> +(defun toggle-display-line-numbers ()
> + (interactive)
> + (if display-line-numbers
> + (setq display-line-numbers nil)
> + (setq display-line-numbers t))
> + (force-mode-line-update))
> 
> Instead of this, about about a minor mode with an intuitive name like "line-numbers-mode"? Above also has an
> issue, I believe.. If user has set display-line-numbers to 'relative, toggling it will always set it back to t.

The menu bar is for simple uses, I see no reason to put all the
complexity of a defcustom on the menu bar.

> How about leaving the buffer local display-line-numbers definition as it is, but replacing
> toggle-display-line-numbers function with a minor mode line-numbers-mode?

Minor mode is probably due anyway, but that is independent of the menu
bar.

Anyway, these are simple things that can always be fixed later.  If
those are the only issues with this new feature, then I'm very lucky
(yeah, right).

Thanks for taking time to try the branch.

======================================================================

(defun scroll-up-benchmark ()
  (interactive)
  (let ((oldgc gcs-done)
        (oldtime (float-time)))
    (condition-case nil (while t (scroll-up) (redisplay))
      (error (message "GCs: %d Elapsed time: %f seconds"
                      (- gcs-done oldgc) (- (float-time) oldtime))))))

Re: Native display of line numbers

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Sat, 17 Jun 2017 17:20:40 +0000
> 
> Of course the line-number-mode to toggle line numbers in just the mode line already exists. 
> 
> Can the same minor mode be reused? Then using a defcustom user can specify:

I don't think we should do that, because the other similar modes
didn't turn off line numbers in the mode line.

Re: Native display of line numbers

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sat, 17 Jun 2017 12:41:50 -0400
> 
> > So with that in mind, I came up with an implementation of a native
> > display of line numbers.
> 
> Cool!

Thanks.

> >   . it works significantly faster (almost twice as fast as linum-mode,
> >     50% faster that relative-line-numbers-mode)
> 
> Should I read this to me that the speed difference w.r.t nlinum is not
> that large, or you didn't bother comparing?

See my other message: I did compare with it, of course, but the
performance was very poor.  Maybe it wasn't supposed to provide a
great performance in a file like xdisp.c.  Or maybe my benchmark is
skewed (in which case I'm sure you will provide a better one).

> >   . it works with R2L text, something the old modes never did
> 
> I didn't know there were problems with R2L text.  Worse: even now that
> you tell me, I can't think of nor find a problem with it (other than the
> choice of whether to display the line numbers in the left or right
> margin).

The fact that the numbers are always displayed on the left is bad
enough; worse, the digits in the numbers are in reverse order.  E.g.,
visit TUTORIAL.he, then turn on linum-mode or nlinum-mode, and watch
the numbers closely.

Re: Native display of line numbers

[Alan Mackenzie]

Hello, Eli.

On Sat, Jun 17, 2017 at 18:12:00 +0300, Eli Zaretskii wrote:
> I generally consider display of line numbers for each line in the
> buffer un-Emacsy, something that came from the dark era when we needed
> to count lines to be able to tell the then existing editors something
> like "move down N lines, then DO SOMETHING".  Emacs pioneered today's
> world where all this is unnecessary, and the rest is history.

> However, many users want line numbers to be displayed in Emacs.  I
> don't know why they want it, perhaps they were "spoiled" by other IDEs
> or something.

I'm not sure either.  One possible use is when using a build process
disjoint from Emacs which gives error and warning messages on a
terminal.  It may be easier to find the pertinent lines if the line
numbers are displayed prominently.  But this is speculation, nothing
more.

> In any case, given the popularity of the various add-on modes which
> insist on displaying line numbers using all kinds of tricks, I don't
> think we can ignore this tendency any longer, even if we agree that
> this is a disease.  The "epidemic" has spread too far and too wide for
> us to continue looking the other way.  And since Emacs doesn't make it
> easy for a Lisp program to invade the holy realm of redisplay, those
> modes use tricks that make Emacs slower and frequently interfere with
> other packages.  They also make demands on the display engine that
> make Emacs harder to develop and maintain.

Yes to all of that.

> So with that in mind, I came up with an implementation of a native
> display of line numbers.  You can find it in the scratch/line-numbers
> branch of the Emacs repository.  Compared with linum-mode,
> nlinum-mode, and other similar modes, it has the following main
> advantages:

>   . it works significantly faster (almost twice as fast as linum-mode,
>     50% faster that relative-line-numbers-mode)
>   . it doesn't use the display margins
>   . it works with R2L text, something the old modes never did

And, for me, the display engine is simply the Right Place to implement
these line numbers.

> The main features of the line-numbering modes are all supported by
> this new feature.

> Please give it a try and report any bugs you find.  I'm sure there
> will be quite a few bugs, given the sheer amount of display feature
> which could be affected, and which I didn't have time to test.

Just one or two minor irritations: it's not clear what face the line
numbers are displayed with; presumably this will become a defcustom in
the finished version.  Also, it's not clear what "relative" line numbers
are, though I dare say it would become clear if I actually tried it
(and I admit I haven't tried RTFM).  ;-)

> Once the flood of serious bug reports dries out, I will look into
> merging this to master.  If, miraculously, no such flood arrives, I
> will merge in a couple of weeks.  When that happens, we will declare
> all the other modes which do the same job deprecated.

I'm in favour of this.

> TIA

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Native display of line numbers

[Sébastien Le Callonnec]

Hi Eli,

On 2017-06-17 16:12:00, Eli Zaretskii wrote:
> Please give it a try and report any bugs you find.  I'm sure there
> will be quite a few bugs, given the sheer amount of display feature
> which could be affected, and which I didn't have time to test.

One issue I am noticing is that line numbers are getting displayed in
the minibuffer, when they are explicitly turned off in linum.el.  This
is particularly obvious when using ido-vertical-mode.

Thanks for tackling this – this already looks like a major improvement
over linum-mode.


Regards,
Sébastien.

Re: Native display of line numbers

[Stefan Monnier]

> nlinum performed so poorly in my benchmarks that I was ashamed of
> publishing the data.  The benchmark entails scrolling through xdisp.c
> one line at a time.

Oh, yes, I think this is the case where there are too many overlays.
There's hope that the new tree-based overlays representation would solve
this problem, but I haven't actually checked.

There are also other ways to circumvent this performance problem, by
flushing the undisplayed overlays every once in a while.  I have some
code for that in nlinum.el, tho it's commented out, because it ends up
triggering re-fontification of the code later on (because currently
jit-lock can't be told to refresh nlinum without also refreshing all
other clients such as font-lock).  It'd be good to improve jit-lock so
this can be done better, but clearly this is one of those cases where
the more you progress, the more work you have to do.


        Stefan

Re: Native display of line numbers

[Stefan Monnier]

>> >   . it works significantly faster (almost twice as fast as linum-mode,
>> >     50% faster that relative-line-numbers-mode)
>> Should I read this to me that the speed difference w.r.t nlinum is not
>> that large, or you didn't bother comparing?
> See my other message: I did compare with it, of course, but the
> performance was very poor.  Maybe it wasn't supposed to provide a
> great performance in a file like xdisp.c.  Or maybe my benchmark is
> skewed (in which case I'm sure you will provide a better one).

Whether or not it's representative doesn't really matter: the
performance you see with nlinum is a real problem when you bump into it.
[ IOW, I'm not here to defend nlinum ;-)  ]

>> >   . it works with R2L text, something the old modes never did
>> I didn't know there were problems with R2L text.  Worse: even now that
>> you tell me, I can't think of nor find a problem with it (other than the
>> choice of whether to display the line numbers in the left or right
>> margin).
>
> The fact that the numbers are always displayed on the left is bad
> enough; worse, the digits in the numbers are in reverse order.  E.g.,
> visit TUTORIAL.he, then turn on linum-mode or nlinum-mode, and watch
> the numbers closely.

Duh, I had tried it, but indeed skipped the "watch the numbers closely"
part.  My naive L2R background makes me think "this looks like
a rendering bug" (especially since if I insert "123" in that tutorial,
it is displayed "123" rather than "321" despite the surrounding R2L
chars, so I wonder how come the digits in the margin end up ordered
"321").


        Stefan

Re: Native display of line numbers

[Stefan Monnier]

> I'm not sure either.  One possible use is when using a build process
> disjoint from Emacs which gives error and warning messages on a
> terminal.  It may be easier to find the pertinent lines if the line
> numbers are displayed prominently.  But this is speculation, nothing
> more.

I think this is more popular nowadays also because of all those screens
that are so short yet so large that you don't really know what to do
with the horizontal real-estate (while suffering from a lack of
vertical real-estate).


        Stefan

Re: Native display of line numbers

[Mathias Dahl]

[-- Attachment #1: Type: text/plain, Size: 6952 bytes --]

Hi,

I have a few comments:

> I generally consider display of line numbers for each line in the
> buffer un-Emacsy, something that came from the dark era when we needed
> to count lines to be able to tell the then existing editors something
> like "move down N lines, then DO SOMETHING".

In my 20 years or so using Emacs, I can probably count on one hand the
number of times I have really wanted/needed to see line numbers
alongside the source code. And when I have had need for it the use has
mainly been what Kaushal Modi also mentions, as a quick way to refer to
one or more lines of code, immediately.

That being said, when playing around with Evil some time back, I
realized that suddenly relative line numbers (see below) were quite
useful. Perhaps this is what you refered to with the dark era. Seems
quite popular nowadays too though, even if I personally have not got the
hang of it. I prefer to "arrow down" (or up) to the line I want to, even
if it might be less optimal from a counting-keystrokes perspective.

> Emacs pioneered today's world where all this is unnecessary, and the
> rest is history.

Are you thinking now about the difference between line editors
and... whatever Emacs is (screen editor?) And, wasn't Emacs too
influenced by the limited display devices that existed back then? I
understand this is not your main point here, but you mentioned it in
your post, so... Not meaning to start an argument, by the way, I'm
mostly curious on your thinking.

> However, many users want line numbers to be displayed in Emacs.  I
> don't know why they want it, perhaps they were "spoiled" by other IDEs
> or something.

Yes, many editors have it and when I use them I seldom find the need
there either. So yes, I think that might be one reason, that people have
"got used to" (it sounds friendlier than "spoiled", I think) line
numbers from there. But, I think also the recent growth of Evil (the Vim
emulator mode, to be clear), Spacemacs and whatnot might have helped
too.

> In any case, given the popularity of the various add-on modes which
> insist on displaying line numbers using all kinds of tricks, I don't
> think we can ignore this tendency any longer, even if we agree that
> this is a disease.

A pragmatic way to look at it, I think many will welcome it.

> The "epidemic" has spread too far and too wide for us to continue
> looking the other way.

I think by now people understood that you really see no need in showing
line numbers alongside the source code... :) Let's not bash those that
do anymore.

> And since Emacs doesn't make it easy for a Lisp program to invade the
> holy realm of redisplay, those modes use tricks that make Emacs slower
> and frequently interfere with other packages.  They also make demands
> on the display engine that make Emacs harder to develop and maintain.

Again, this sounds really good, and a pragmatic way to solve things.

I will include here a comment from a later reply:

> > Can you please add support for highlighting the current line number,
> > using a different face (See the highlighted line number by nlinum on
> > the right hand side)?

> Is it really important?  Why? do people really have difficulty finding
> the line where point/cursor is?

I think it is a useful visual help/guide and probably is extra useful
when your cursor is not close to the left side of the window. When
moving up and down to a certain line, your eyes can look at the line
number in the edge that changes color, instead of trying to match where
the cursor is compared to the numbers in the edge. Of course, that exact
scenario can be done with Emacs traditional way to show line numbers on
the mode line as well. Anyway, I can easily see that it is useful to
highlight the current line number, even if I am not using it myself
much. It's a visual help, simply.

Some have touched on this subject here, but I will do it anyway:
relative line numbers seems like a useful tool to some people. For those
who haven't tried it, it works like this:

 3 ...
 2 Other line
 1 Other line
 0 This is the line I am on...
 1 Other line
 2 Other line
 3 ...

With relative line numbers it is quite easy to use a numeric argument to
move a certain number of lines up or down.

There is a risk now, when commenting on these "little things", that the
focus
shifts from the primary goal you had, to show line numbers in a more
efficient
and stable manner, to only discuss the small things. It is not my meaning,
and I am glad to see you are thinking to add such a feature to Emacs since
I think many users will like it, even if the reason is they are "spoiled"
(now I
said it too... :)

Thanks for listening!

/Mathias


On Sat, Jun 17, 2017 at 5:12 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> I generally consider display of line numbers for each line in the
> buffer un-Emacsy, something that came from the dark era when we needed
> to count lines to be able to tell the then existing editors something
> like "move down N lines, then DO SOMETHING".  Emacs pioneered today's
> world where all this is unnecessary, and the rest is history.
>
> However, many users want line numbers to be displayed in Emacs.  I
> don't know why they want it, perhaps they were "spoiled" by other IDEs
> or something.  In any case, given the popularity of the various add-on
> modes which insist on displaying line numbers using all kinds of
> tricks, I don't think we can ignore this tendency any longer, even if
> we agree that this is a disease.  The "epidemic" has spread too far
> and too wide for us to continue looking the other way.  And since
> Emacs doesn't make it easy for a Lisp program to invade the holy realm
> of redisplay, those modes use tricks that make Emacs slower and
> frequently interfere with other packages.  They also make demands on
> the display engine that make Emacs harder to develop and maintain.
>
> So with that in mind, I came up with an implementation of a native
> display of line numbers.  You can find it in the scratch/line-numbers
> branch of the Emacs repository.  Compared with linum-mode,
> nlinum-mode, and other similar modes, it has the following main
> advantages:
>
>   . it works significantly faster (almost twice as fast as linum-mode,
>     50% faster that relative-line-numbers-mode)
>   . it doesn't use the display margins
>   . it works with R2L text, something the old modes never did
>
> The main features of the line-numbering modes are all supported by
> this new feature.
>
> Please give it a try and report any bugs you find.  I'm sure there
> will be quite a few bugs, given the sheer amount of display feature
> which could be affected, and which I didn't have time to test.
>
> Once the flood of serious bug reports dries out, I will look into
> merging this to master.  If, miraculously, no such flood arrives, I
> will merge in a couple of weeks.  When that happens, we will declare
> all the other modes which do the same job deprecated.
>
> TIA
>
>

[-- Attachment #2: Type: text/html, Size: 8846 bytes --]

Re: Native display of line numbers

[James Nguyen]

> In my 20 years or so using Emacs, I can probably count on one hand the
> number of times I have really wanted/needed to see line numbers
> alongside the source code. And when I have had need for it the use has
> mainly been what Kaushal Modi also mentions, as a quick way to refer to
> one or more lines of code, immediately.

It's useful for other things too, like pair programming, "From line 22 - 33, etc...".

If you use Evil, even without Relative Numbers, it's useful to look at a line
and say Go to line 33.

Visual in memory placemarker as you scroll through code.
"Oh this is around line 900...".

Not saying there aren't other ways to achieve the goal but line numbers do
have uses..

> In any case, given the popularity of the various add-on modes which
> insist on displaying line numbers using all kinds of tricks, I don't
> think we can ignore this tendency any longer, even if we agree that
> this is a disease.

>> A pragmatic way to look at it, I think many will welcome it.

While we're on this topic, I wonder how feasible it would be to do smooth pixel
scrolling at the C layer.

> > Can you please add support for highlighting the current line number,
> > using a different face (See the highlighted line number by nlinum on
> > the right hand side)?

> Is it really important?  Why? do people really have difficulty finding
> the line where point/cursor is?

I like how nlinum highlights the current line with a different face. I think
it's a nice UI polish item. (Not everything has to be 100% for functional
                                 purposes.)

-

For Relative Numbers, a feature request would be to have the current line
represent the current line number instead of 0. I think vim 8 does that
for relative numbers.

Example:

3
2
1
456
1
2
3

Re: Native display of line numbers

[Joseph Garvin]

[-- Attachment #1: Type: text/plain, Size: 849 bytes --]

I just signed up for the devel list to chime in: I'm a user with a real use
case for line numbers, and it's not a disease ;)

I have RSI in my hands. Myself and some other emacsers use speech
recognition driving emacs to code. The latency for speech recognition is
not great though, and so your best bet for speed is to utter a series of
commands all at once, anticipating the outcome from doing all of those
actions in sequence. For this it's essential to have *relative* line
numbers, so that you can say things like, "up 5, delete 3, down 2". Which
is pretty much the scenario you describe, it's just there's a reason to do
it still in 2017.

So I'd welcome any new code that speeds up line number calculation,
although it'd be nice if it had a relative mode. What about absolute line
#s? I have no idea what those heretics use it for ;)

Joe G.

[-- Attachment #2: Type: text/html, Size: 981 bytes --]

Re: Native display of line numbers

[Eli Zaretskii]

> Date: Sat, 17 Jun 2017 20:27:02 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> Just one or two minor irritations: it's not clear what face the line
> numbers are displayed with; presumably this will become a defcustom in
> the finished version.

There's already a special face for that, 'line-number', I just forgot
to mention it in NEWS.

> Also, it's not clear what "relative" line numbers are, though I dare
> say it would become clear if I actually tried it (and I admit I
> haven't tried RTFM).  ;-)

Yes, do try.  (The manual will describe this in more detail.)

> I'm in favour of this.

Thanks.

Re: Native display of line numbers

[Eli Zaretskii]

> From: Sébastien Le Callonnec <sebastien@weblogism.com>
> Cc: Eli Zaretskii <eliz@gnu.org>
> Date: Sat, 17 Jun 2017 21:47:50 +0100
> 
> One issue I am noticing is that line numbers are getting displayed in
> the minibuffer

Only if you use setq-default to turn on the line numbers in all
buffers, I presume?  You can always turn it off explicitly in that
buffer (and any other buffer where you don't want it).

I wasn't sure no one will want numbers in the minibuffer, so I didn't
forced them off there.  I'd like to hear more opinions before deciding
on this.

Thanks.

Re: Native display of line numbers

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 3605 bytes --]

On Sat, Jun 17, 2017 at 1:41 PM Eli Zaretskii <eliz@gnu.org> wrote:

> nlinum performed so poorly in my benchmarks that I was ashamed of
> publishing the data.  The benchmark entails scrolling through xdisp.c
> one line at a time.  The code is at the end of this message (it was
> posted by Dmitry Antipov), you can try it yourself.


Thanks. I haven't yet tried that. I do not work in C most of the time and
so may be I never noticed it. nlinum has been super smooth for me (with the
current line highlight enabled too) for the major modes that I am working
on. I have been using nlinum for many many years now, and the current line
highlighting feature for the past year.


> Is it really important?  Why? do people really have difficulty finding
> the line where point/cursor is?
>

It reduces cognitive load in my experience. I need to refer to the line
numbers more frequently than some; I frequently do code reviews, discuss
code change with colleagues at remote locations. So with if my cursor is at
the beginning of a function definition, it's really quick to glance to the
left, look at the highlighted number, and tell the other people "jump to X
line", instead of asking them to search for a function name, etc. I can
look in the mode line too to get the line number. But this quick left
glance to tell the current line num is much faster than looking for the
line number in the mode line.


> I could add this feature if it's deemed important, but it will slow
> down redisplay to some extent, because cursor motion can no longer be
> considered affecting the cursor alone.
>

Even if this feature is enabled, I believe that it would have a defcustom.
If nlinum with current line highlighting is working fine, I think this
should perform even better.

The presence of packages like https://github.com/tom-tan/hlinum-mode,
https://github.com/hlissner/emacs-nlinum-hl, and many people asking how to
highlight the current line number on external emacs forums (like
emacs.stackexchange.com or reddit.com/r/emacs) tells that many people would
appreciate this feature.

The menu bar is for simple uses, I see no reason to put all the
> complexity of a defcustom on the menu bar.
>

The toggle-display-line-numbers is an interactive function though. So
someone can unknowingly bind it to a key to toggle line numbers and get
confused why their setting to show relative line numbers is getting lost.
It also needs a doc-string saying that that function is only for use from
the menu bar, and point the user to look at display-line-numbers var
instead to do what they want. Also if that function is intended to be
called only from the menu bar, should it be prefixed with "menu-bar-"? It
would go against the convention used in that file, but it adds clarity.


> Minor mode is probably due anyway, but that is independent of the menu
> bar.
>
> Anyway, these are simple things that can always be fixed later.


Understood.


> Thanks for taking time to try the branch.
>

Thanks for working on this.

On Sat, Jun 17, 2017 at 1:42 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > Can the same minor mode be reused? Then using a defcustom user can
> specify:
>
> I don't think we should do that, because the other similar modes
> didn't turn off line numbers in the mode line.


I didn't follow that. But I also see that line-number-mode is a global
minor mode. For this line numbers feature, we need a mode that can be
enabled just locally or globally.

We definitely need a more intuitive minor mode name for this. If this
feature is a superset of linum-mode, then may be just call that.
-- 

Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 5271 bytes --]

Re: Native display of line numbers

[martin rudalics]

Thanks - a wise step.

 > Please give it a try and report any bugs you find.  I'm sure there
 > will be quite a few bugs, given the sheer amount of display feature
 > which could be affected, and which I didn't have time to test.

One problem I see is that once a window has been scrolled to the right,
it's not easy to auto-hscroll it back, at least with ‘truncate-lines’
non-nil.  For example, when with emacs -Q I here do

(progn
   (setq truncate-lines t)
   (find-file "./src/xdisp.c")
   (split-window-horizontally)
   (other-window 1)
   (goto-char (point-max))
   (end-of-line -5)
   (setq display-line-numbers t)
   (sit-for 1)
   (beginning-of-line))

the line beginnings in the window on the right won't become visible
again as long as I do just ‘left-char’.

martin

Re: Native display of line numbers

[martin rudalics]

 > (progn
 >    (setq truncate-lines t)

Silly, admittedly.  The ‘split-window-horizontally’ below does the job.

 >    (find-file "./src/xdisp.c")
 >    (split-window-horizontally)

Or setting ‘truncate-lines’ in the xdisp.c buffer.

martin

Re: Native display of line numbers

[Sébastien Le Callonnec]

Hi Eli,

On 2017-06-18 03:38:05, Eli Zaretskii wrote:
> Only if you use setq-default to turn on the line numbers in all
> buffers, I presume?  You can always turn it off explicitly in that
> buffer (and any other buffer where you don't want it).

I used customize-option which I presume is akin to setting
`display-line-numbers' in all buffers, yes.

I now use something like this, which actually sounds closer to what you
had in mind:

(add-hook 'prog-mode-hook
          (lambda () (setq-local display-line-numbers t)))


>
> I wasn't sure no one will want numbers in the minibuffer, so I didn't
> forced them off there.  I'd like to hear more opinions before deciding
> on this.

If not using something like ido-vertical-mode, I would find that line
number confusing but also pointless in the minibuffer.  But I understand
you're building an “opt-in” feature, rather an “opt-out” one as provided
by `global-linum-mode' (widely recommended as a method to turn on line
numbering).

> Thanks.


Thank you,
Sébastien.

Re: Native display of line numbers

[Yuri Khan]

On Sat, Jun 17, 2017 at 10:12 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> I came up with an implementation of a native
> display of line numbers.  You can find it in the scratch/line-numbers
> branch of the Emacs repository.

It is nice to have native line numbers. They work with a non-default
background, correctly handle line wrapping, and even when their face
is customized to a smaller size. (In a larger size, their tops get
truncated, but that’s firmly in the “don’t to that, then” territory.)

But now we have three facilities that can display auxiliary
information around the buffer text: margin, fringe, and line numbers,
all with their own unique limitations:

* The margin’s limitation is that its overall background is defined by
the default face. Fragments of text are displayed in the margin can
specify their own background, but the space where nothing is displayed
is always the same color as the buffer. Also, overlay performance.

* The fringe can only display bitmaps, only monochrome bitmaps, and
only bitmaps at native display resolution. Which makes all bitmaps
that are designed for low resolution displays unreadably tiny on a
HiDPI display.

* And the line numbers area only displays line numbers.


The relative ordering of the margin and fringe can be customized with
‘fringes-outside-margins’ but line numbers are always inside both of
those. That means a line number area with a non-default background
color will visually divide the display. Also, the line wrapping
indicator in the fringe is visually separated from the wrapped line.
IMO, it should be possible to put the fringe, and maybe the margin,
inside line numbers.

Re: Native display of line numbers

[Alan Mackenzie]

Hello, Eli.

On Sun, Jun 18, 2017 at 05:35:34 +0300, Eli Zaretskii wrote:
> > Date: Sat, 17 Jun 2017 20:27:02 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

[ .... ]

> > Also, it's not clear what "relative" line numbers are, though I dare
> > say it would become clear if I actually tried it (and I admit I
> > haven't tried RTFM).  ;-)

> Yes, do try.  (The manual will describe this in more detail.)

I've just tried it.  It works mostly well, except...

1. Enable relative line numbers globally.
2. Visit a file, put it in two or several side by side windows.
3. Start follow-mode.

The relative line numbers are now "global", in that they are relative to
point in the selected window.

4. Do something, such as C-n, which causes a redisplay.

The relative numbers are now "local", in that they are relative to point
in each window.  It is not clear how to recover the "global" relative
line numbers, except by restarting follow-mode.

I think it would be best if the "global" relative line numbers could be
made to work.  If not, it would be better if the "local" line numbers
appeared after M-x follow-mode.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Native display of line numbers

[Colin Baxter]

>>>>> "Alan" == Alan Mackenzie <acm@muc.de> writes:

    Alan> I've just tried it.  It works mostly well, except...

    Alan> 1. Enable relative line numbers globally.  2. Visit a file,
    Alan> put it in two or several side by side windows.  3. Start
    Alan> follow-mode.

    Alan> The relative line numbers are now "global", in that they are
    Alan> relative to point in the selected window.

I was thinking of mentioning this, but you beat me to it.

I would like to add a remark in defence of line numbers. I always use
them with the exception of certain modes, e.g. org-mode, gnus. I work
mainly on large tex files and find line numbers useful in giving me a
sense of where I am in the document. Ok there are other ways of doing
that, but I wouldn't want to change.


-- 
--
Colin Baxter
m43cap@yandex.com
GnuPG fingerprint: 68A8 799C 0230 16E7 BF68  2A27 BBFA 2492 91F5 41C8

Re: Native display of line numbers

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sat, 17 Jun 2017 17:25:44 -0400
> 
> Whether or not it's representative doesn't really matter: the
> performance you see with nlinum is a real problem when you bump into it.
> [ IOW, I'm not here to defend nlinum ;-)  ]

Well, it's not about defending, it's about benchmarking the new code
relative to the old one.  I was worried that constantly counting lines
during redisplay might be a significant setback, and was relieved to
find out that wasn't the case.

> > The fact that the numbers are always displayed on the left is bad
> > enough; worse, the digits in the numbers are in reverse order.  E.g.,
> > visit TUTORIAL.he, then turn on linum-mode or nlinum-mode, and watch
> > the numbers closely.
> 
> Duh, I had tried it, but indeed skipped the "watch the numbers closely"
> part.  My naive L2R background makes me think "this looks like
> a rendering bug"

It could be a rendering bug, indeed.  In general, how to render
bidirectional text in the margins is a dark corner, since it isn't
clear whether the bidi context of the buffer text is relevant or not.

Re: Native display of line numbers

[Eli Zaretskii]

> From: Mathias Dahl <mathias.dahl@gmail.com>
> Date: Sat, 17 Jun 2017 23:32:13 +0200
> Cc: emacs-devel@gnu.org
> 
> > Emacs pioneered today's world where all this is unnecessary, and the
> > rest is history.
> 
> Are you thinking now about the difference between line editors
> and... whatever Emacs is (screen editor?) And, wasn't Emacs too
> influenced by the limited display devices that existed back then? I
> understand this is not your main point here, but you mentioned it in
> your post, so... Not meaning to start an argument, by the way, I'm
> mostly curious on your thinking.

What I had in mind was the Emacs commands which accept prefix argument
to mean how many lines to move/copy/delete/whatever.  E.g., "C-u C-u C-n",
something AFAIK no other editor has to this day.

> > > Can you please add support for highlighting the current line number,
> > > using a different face (See the highlighted line number by nlinum on
> > > the right hand side)?
> 
> > Is it really important? Why? do people really have difficulty finding
> > the line where point/cursor is?
> 
> I think it is a useful visual help/guide and probably is extra useful
> when your cursor is not close to the left side of the window.

Given the responses, I guess we will need to have this sub-mode as well.

Thanks for the feedback.

Re: Native display of line numbers

[Eli Zaretskii]

> From: James Nguyen <jamesn@fastmail.com>
> Date: Sat, 17 Jun 2017 15:12:04 -0700
> Cc: Eli Zaretskii <eliz@gnu.org>,
>  emacs-devel@gnu.org
> 
> While we're on this topic, I wonder how feasible it would be to do smooth pixel
> scrolling at the C layer.

On the device-independent level, this is already supported, has been
since Emacs 21.  Emacs 26 has a minor mode which uses this to provide
pixel-level smooth scroll commands.  But they slow down scrolling, so
some people might not like that.  And the only way I can think of to
implement a faster smooth scrolling is to do that in terminal-specific
code, i.e. separately for X, w32, and NS.  Patches are welcome.

> I like how nlinum highlights the current line with a different face. I think
> it's a nice UI polish item. (Not everything has to be 100% for functional
>                                  purposes.)
> 
> -
> 
> For Relative Numbers, a feature request would be to have the current line
> represent the current line number instead of 0. I think vim 8 does that
> for relative numbers.

I guess this will have to be added, thanks for the feedback.

Re: Native display of line numbers

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Sun, 18 Jun 2017 04:27:38 +0000
> Cc: emacs-devel@gnu.org
> 
>  The menu bar is for simple uses, I see no reason to put all the
>  complexity of a defcustom on the menu bar.
> 
> The toggle-display-line-numbers is an interactive function though. So someone can unknowingly bind it to a
> key to toggle line numbers and get confused why their setting to show relative line numbers is getting lost. It
> also needs a doc-string saying that that function is only for use from the menu bar, and point the user to look
> at display-line-numbers var instead to do what they want. Also if that function is intended to be called only from
> the menu bar, should it be prefixed with "menu-bar-"? It would go against the convention used in that file, but it
> adds clarity.

I think I'll leave it to someone else to improve the interactive
customization facilities, once the feature lands on master.  I'm not
really good with that stuff, so I think I will provide the
infrastructure and the initial customization capabilities, and let
others pick up where I left off.

Thanks again for the feedback.

Re: Native display of line numbers

[Andreas Schwab]

On Jun 18 2017, Eli Zaretskii <eliz@gnu.org> wrote:

> What I had in mind was the Emacs commands which accept prefix argument
> to mean how many lines to move/copy/delete/whatever.  E.g., "C-u C-u C-n",
> something AFAIK no other editor has to this day.

Except vi.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Native display of line numbers

[Eli Zaretskii]

> Date: Sun, 18 Jun 2017 10:44:36 +0200
> From: martin rudalics <rudalics@gmx.at>
> 
> One problem I see is that once a window has been scrolled to the right,
> it's not easy to auto-hscroll it back, at least with ‘truncate-lines’
> non-nil.

Yes, truncated lines have a few bugs with this feature, I have a todo
item to look into that.  Thanks for the test case.

Re: Native display of line numbers

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Sun, 18 Jun 2017 18:03:18 +0700
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> On Sat, Jun 17, 2017 at 10:12 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > I came up with an implementation of a native
> > display of line numbers.  You can find it in the scratch/line-numbers
> > branch of the Emacs repository.
> 
> It is nice to have native line numbers. They work with a non-default
> background, correctly handle line wrapping, and even when their face
> is customized to a smaller size. (In a larger size, their tops get
> truncated, but that’s firmly in the “don’t to that, then” territory.)

Hmm... that ought to work.  Something's amiss, I'll take a look.

I agree that it's a strange thing to do, but bitter experience has
taught me that for every strange customization there's a more-or-less
valid use case out there, so it's better to have the code follow the
expectations than have bug reports ;-)

> But now we have three facilities that can display auxiliary
> information around the buffer text: margin, fringe, and line numbers,
> all with their own unique limitations:
> 
> * The margin’s limitation is that its overall background is defined by
> the default face. Fragments of text are displayed in the margin can
> specify their own background, but the space where nothing is displayed
> is always the same color as the buffer. Also, overlay performance.

(You can write in the margins using 'display' text properties you put
on buffer text or on line-prefix strings.)

> * The fringe can only display bitmaps, only monochrome bitmaps, and
> only bitmaps at native display resolution. Which makes all bitmaps
> that are designed for low resolution displays unreadably tiny on a
> HiDPI display.
> 
> * And the line numbers area only displays line numbers.
> 
> 
> The relative ordering of the margin and fringe can be customized with
> ‘fringes-outside-margins’ but line numbers are always inside both of
> those. That means a line number area with a non-default background
> color will visually divide the display. Also, the line wrapping
> indicator in the fringe is visually separated from the wrapped line.
> IMO, it should be possible to put the fringe, and maybe the margin,
> inside line numbers.

That would AFAIU require a change in basic design of the screen
layout: it currently assumes only 3 areas, the 2 margins and the text
area.

But I'm not sure I understand the motivation: is it due to the
background issues with the margins?  If so, fixing that might be much
easier.

Re: Native display of line numbers

[Eli Zaretskii]

> Date: Sun, 18 Jun 2017 11:42:51 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> 1. Enable relative line numbers globally.
> 2. Visit a file, put it in two or several side by side windows.
> 3. Start follow-mode.
> 
> The relative line numbers are now "global", in that they are relative to
> point in the selected window.

That's not what I see.  I guess you see that because you activate
line-number display when both windows had the same value of point.  If
you move point in one of the windows before activating line numbers,
you will see that the relative numbers are local to each window.  This
is by design, and the add-on package relative-line-numbers does the
same.

> 4. Do something, such as C-n, which causes a redisplay.
> 
> The relative numbers are now "local", in that they are relative to point
> in each window.

Well, here they are local to begin with.

> I think it would be best if the "global" relative line numbers could be
> made to work.

Given a window whose buffer is in Follow Mode, how do I know what is
the "correct" value of point to use in that window to make the
relative numbers "global"?

> If not, it would be better if the "local" line numbers appeared
> after M-x follow-mode.

Well, they are local here to begin with.  Maybe I didn't understand
your recipe -- can you show it in full detail, with all the commands
you type?

Re: Native display of line numbers

[Alan Mackenzie]

Hello, Eli.

On Sun, Jun 18, 2017 at 18:06:36 +0300, Eli Zaretskii wrote:
> > Date: Sun, 18 Jun 2017 11:42:51 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > 1. Enable relative line numbers globally.
> > 2. Visit a file, put it in two or several side by side windows.
> > 3. Start follow-mode.

> > The relative line numbers are now "global", in that they are relative to
> > point in the selected window.

> That's not what I see.  I guess you see that because you activate
> line-number display when both windows had the same value of point.

Line-number display was already globally enabled when the windows were
created.  But point in each window was indeed the same (see my function 
`3-column' below).

> If you move point in one of the windows before activating line numbers,
> you will see that the relative numbers are local to each window.  This
> is by design, and the add-on package relative-line-numbers does the
> same.

> > 4. Do something, such as C-n, which causes a redisplay.

> > The relative numbers are now "local", in that they are relative to point
> > in each window.

> Well, here they are local to begin with.

> > I think it would be best if the "global" relative line numbers could be
> > made to work.

> Given a window whose buffer is in Follow Mode, how do I know what is
> the "correct" value of point to use in that window to make the
> relative numbers "global"?

I don't see that this can easily be done, since follow-mode more fights
the display engine rather than working with it.  The display engine is
currently unaware of follow-mode.  My comment was partly to point out how
nice it would be if follow-mode support could be implemented in the
display engine.

> > If not, it would be better if the "local" line numbers appeared
> > after M-x follow-mode.

> Well, they are local here to begin with.  Maybe I didn't understand
> your recipe -- can you show it in full detail, with all the commands
> you type?

OK.

Firstly, I found this on a Linux tty, but it appears in an X session,
too.

$ emacs --no-desktop
M-x customize-variable<RET>display-line-numbers<RET>
  <set display-line-numbers to relative using the keyboard or mouse and
  save it for the session>
C-x C-f path/to/src/xdisp.c
If in X, maximise the selected window using the mouse.
C-c 3 ; see below.

The displayed line-numbers are now "global", and range from 0 to 194

C-n

The displayed line-numbers in the "other two" windows now range from -31
to 33.

########################################################################
(defun 3-column ()
  "Disply the current buffer in 3 columns with Follow Mode"
  (interactive)
  (follow-mode 1)
  (delete-other-windows)
  (split-window-horizontally) (split-window-horizontally)
  (balance-windows))
(global-set-key "\C-c3" '3-column)
########################################################################

I've found another bug, I'm afraid.  Starting off from the above
situation, with point in the middle window (in X windows), do M-<.  The
relative line numbers in the middle window now range from -59 to -20,
with that window's point at relative line -39.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Native display of line numbers

[Eli Zaretskii]

> Date: Sun, 18 Jun 2017 15:47:05 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > Given a window whose buffer is in Follow Mode, how do I know what is
> > the "correct" value of point to use in that window to make the
> > relative numbers "global"?
> 
> I don't see that this can easily be done, since follow-mode more fights
> the display engine rather than working with it.

Maybe follow-mode could provide a buffer-local variable with the value
of that point, and the display engine could simply access that
variable?

> $ emacs --no-desktop
> M-x customize-variable<RET>display-line-numbers<RET>
>   <set display-line-numbers to relative using the keyboard or mouse and
>   save it for the session>
> C-x C-f path/to/src/xdisp.c
> If in X, maximise the selected window using the mouse.
> C-c 3 ; see below.
> 
> The displayed line-numbers are now "global", and range from 0 to 194
> 
> C-n
> 
> The displayed line-numbers in the "other two" windows now range from -31
> to 33.
> 
> ########################################################################
> (defun 3-column ()
>   "Disply the current buffer in 3 columns with Follow Mode"
>   (interactive)
>   (follow-mode 1)
>   (delete-other-windows)
>   (split-window-horizontally) (split-window-horizontally)
>   (balance-windows))
> (global-set-key "\C-c3" '3-column)
> ########################################################################
> 
> I've found another bug, I'm afraid.  Starting off from the above
> situation, with point in the middle window (in X windows), do M-<.  The
> relative line numbers in the middle window now range from -59 to -20,
> with that window's point at relative line -39.

Thanks.  Both situations are redisplay bugs: if you trigger redisplay
in both of them, the line numbers are again window-local.  I need to
find a redisplay optimization that prevents that from happening
automatically.

Re: Native display of line numbers

[Yuri Khan]

On Sun, Jun 18, 2017 at 9:54 PM, Eli Zaretskii <eliz@gnu.org> wrote:

>> The relative ordering of the margin and fringe can be customized with
>> ‘fringes-outside-margins’ but line numbers are always inside both of
>> those. That means a line number area with a non-default background
>> color will visually divide the display. Also, the line wrapping
>> indicator in the fringe is visually separated from the wrapped line.
>> IMO, it should be possible to put the fringe, and maybe the margin,
>> inside line numbers.
>
> That would AFAIU require a change in basic design of the screen
> layout: it currently assumes only 3 areas, the 2 margins and the text
> area.
>
> But I'm not sure I understand the motivation: is it due to the
> background issues with the margins?  If so, fixing that might be much
> easier.

The base motivation is to have an intuitive ordering of out-of-buffer
adornments. Out of the box in Emacs, there are:

* line numbers
* line wrap indicators
* horizontal scrolling indicators
* debugging overlay arrows

Some IDEs also display in their gutters:

* change bars indicating modifications since the last commit (in
Emacs, see Git-Gutter)
* in-buffer bookmark indicators (functionality of bm.el)
* folding indicators and controls (functionality of outline-minor-mode)
* static analysis warnings (flycheck)

Some of these attract to the buffer text more strongly than others.


Let’s take scrolling indicators, because it’s easiest to explain the logic.

Suppose a long line:

    Lorem ipsum dolor sit amet, consectetur wgah’nagl fhtagn.

We put it in a narrow window:

    Lorem ipsum dolor sit amet, consectetur »

We can scroll it horizontally:

    « sit amet, consectetur wgah’nagl fhtagn.

So far, in all cases, a scrolling indicator implies some text is
elided at this point.

Now we enable line numbers. As is:

    « 42  amet, consectetur wgah’nagl fhtagn.

If the elided text were inserted at the position of the indicator, the
line number would end up in the middle of the line. Compare:

    42 «t amet, consectetur wgah’nagl fhtagn.


Similarly, a pair of wrapping indicators serves as a “portal” which a
long line enters and another “portal” out of which the continuation
emerges. They want to be immediately adjacent to the line.

    42 Lorem ipsum dolor sit amet, consectetu}
      }r wgah’nagl fhtagn.


If the margin background issue were fixed but line numbers remained
closely tied to the buffer, I would probably continue using the now
deprecated linum-mode, because this configuration gives me the
intuitive ordering.

Re: Native display of line numbers

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Sun, 18 Jun 2017 23:54:38 +0700
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> > But I'm not sure I understand the motivation: is it due to the
> > background issues with the margins?  If so, fixing that might be much
> > easier.
> 
> The base motivation is to have an intuitive ordering of out-of-buffer
> adornments. Out of the box in Emacs, there are:
> 
> * line numbers
> * line wrap indicators
> * horizontal scrolling indicators
> * debugging overlay arrows
> 
> Some IDEs also display in their gutters:
> 
> * change bars indicating modifications since the last commit (in
> Emacs, see Git-Gutter)
> * in-buffer bookmark indicators (functionality of bm.el)
> * folding indicators and controls (functionality of outline-minor-mode)
> * static analysis warnings (flycheck)
> 
> Some of these attract to the buffer text more strongly than others.

Yes, but why is that a problem?  And if some combinations are really
too much, then are those combinations really that frequent that they
should be source of a worry?  And if they are, how come this wasn't an
issue until now?

>     « sit amet, consectetur wgah’nagl fhtagn.
> 
> So far, in all cases, a scrolling indicator implies some text is
> elided at this point.
> 
> Now we enable line numbers. As is:
> 
>     « 42  amet, consectetur wgah’nagl fhtagn.
> 
> If the elided text were inserted at the position of the indicator, the
> line number would end up in the middle of the line. Compare:
> 
>     42 «t amet, consectetur wgah’nagl fhtagn.

OK, and what's your point?  That the line number display is not ideal?
I agree, but I think the alternatives are much worse.  E.g., switching
the order can only work on TTY frames and when the fringes are
disabled, so it cannot be done by default, or we will have
inconsistent behavior.  I'm sure people who like line numbers will get
used to the arrangement of indicators soon enough; I did.  Especially
since long lines are rare in source code buffers, at least IME.

> If the margin background issue were fixed but line numbers remained
> closely tied to the buffer, I would probably continue using the now
> deprecated linum-mode, because this configuration gives me the
> intuitive ordering.

Experience shows that using the margins for such pervasive modes is
trouble in itself, because there are modes which want to use the
margins for their own purposes.  We still don't have a satisfactory
solution for those problems.  Displaying the numbers in the text area
solves them by simply keeping its hands off the margins.  I think the
gains here outweigh the minor disadvantages by a large margin (pun
intended), so I'd rather pay those small "fines" to have a cleaner
solution for margin usage, let alone a much faster redisplay (have you
tried relative-line-numbers-mode in windows under Follow Mode?).

Re: Native display of line numbers

[Daniele Nicolodi]

On 17/06/17 09:12, Eli Zaretskii wrote:
> So with that in mind, I came up with an implementation of a native
> display of line numbers.  You can find it in the scratch/line-numbers
> branch of the Emacs repository.

I though there were am hard veto on the implementation of any new
functionality in C code, because reasons.

Cheers,
Daniele

Re: Native display of line numbers

[Eli Zaretskii]

> From: Daniele Nicolodi <daniele@grinta.net>
> Date: Sun, 18 Jun 2017 13:41:04 -0600
> 
> I though there were am hard veto on the implementation of any new
> functionality in C code, because reasons.

Evidently, this impression was based on some misunderstanding.  New
Emacs features are coded in C all the time, e.g. see the recently
added command replace-buffer-contents.

Re: Native display of line numbers

[Alan Mackenzie]

Hello, Eli.

On Sun, Jun 18, 2017 at 19:11:27 +0300, Eli Zaretskii wrote:
> > Date: Sun, 18 Jun 2017 15:47:05 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > Given a window whose buffer is in Follow Mode, how do I know what is
> > > the "correct" value of point to use in that window to make the
> > > relative numbers "global"?

> > I don't see that this can easily be done, since follow-mode more fights
> > the display engine rather than working with it.

> Maybe follow-mode could provide a buffer-local variable with the value
> of that point, and the display engine could simply access that
> variable?

Or something like that.  How about a buffer local variable provided by
the display engine called something like point-window?  Any function
(here, we're talking mainly follow-mode) could set this to a window, and
the meaning would be "all relative line numbers should be based from the
value of point in this window".  This would save the display engine from
having to check the existence of the variable (follow-mode might not be
loaded), and updating the value of the variable in follow-mode would be
straightforward.

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Native display of line numbers

[Daniele Nicolodi]

On 18/06/17 14:04, Eli Zaretskii wrote:
>> From: Daniele Nicolodi <daniele@grinta.net>
>> Date: Sun, 18 Jun 2017 13:41:04 -0600
>>
>> I though there were am hard veto on the implementation of any new
>> functionality in C code, because reasons.
> 
> Evidently, this impression was based on some misunderstanding.  New
> Emacs features are coded in C all the time, e.g. see the recently
> added command replace-buffer-contents.

Evidently, I was under the impression that the portable dumper idea was
rejected mainly on the base that it is coded in C while a possible
solution exists taht can be implemented in elisp.

Cheers,
Daniele

Re: Native display of line numbers

[Scott Jaderholm]

Eli,

It would be nice to be able to display both absolute and relative line
numbers at the same time, with each having their own face.

Perhaps the format could be customizable, though I don't personally need
that if you put absolute to the left of relative, and so long as numbers
are right aligned, which they are currently..

Example: http://imgur.com/a/2ofpS

Thanks for your work on line numbers,
Scott

Re: Native display of line numbers

[James Nguyen]

>> On the device-independent level, this is already supported, has been
>> since Emacs 21.  Emacs 26 has a minor mode which uses this to provide
>> pixel-level smooth scroll commands.  But they slow down scrolling, so
>> some people might not like that.  And the only way I can think of to
>> implement a faster smooth scrolling is to do that in terminal-specific
>> code, i.e. separately for X, w32, and NS.  Patches are welcome.

I'm not sure how to get started doing that. The pixel-scroll-mode is very nice,
but a little too slow for my liking.

Sublime Text like pixel scrolling would probably be my highest wish list item.
(Well, up there with handling ~very~ long lines.)

Sublime is able to handle Macbook Touchpad scrolling as well as a mouse responsively.

>> I guess this will have to be added, thanks for the feedback.

Thanks! This is great.

# Some things I noticed:

1. Overlays might mess with the line numbers.

Using company-mode along with display-line-numbers. The overlay gets a little
janky and the line numbers disappear where the overlay shows up.

Here's a pic I found from reddit detailing the same thing.

https://i.imgur.com/qXSJDrv.png

2. Haven't been able to reproduce it, but I was scrolling downwards with a Macbook
Touchpad with relative numbers and the numbers kept toggling back to the absolute
version. Scrolling up was fine.

Re: Native display of line numbers

[Eli Zaretskii]

> Date: Sun, 18 Jun 2017 20:19:33 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > Maybe follow-mode could provide a buffer-local variable with the value
> > of that point, and the display engine could simply access that
> > variable?
> 
> Or something like that.  How about a buffer local variable provided by
> the display engine called something like point-window?  Any function
> (here, we're talking mainly follow-mode) could set this to a window, and
> the meaning would be "all relative line numbers should be based from the
> value of point in this window".  This would save the display engine from
> having to check the existence of the variable (follow-mode might not be
> loaded), and updating the value of the variable in follow-mode would be
> straightforward.

That's fine as well, but might be harder to implement, and also
calling Lisp from within the display engine is something I think
should be kept to a minimum.

With my suggestion, checking whether Follow mode is one of buffer's
minor modes is simple enough, and Follow mode should (AFAIU) always
know where's its "point" located, so having a variable with that value
should also be simple.

Re: Native display of line numbers

[Eli Zaretskii]

> From: Daniele Nicolodi <daniele@grinta.net>
> Date: Sun, 18 Jun 2017 14:48:41 -0600
> 
> > Evidently, this impression was based on some misunderstanding.  New
> > Emacs features are coded in C all the time, e.g. see the recently
> > added command replace-buffer-contents.
> 
> Evidently, I was under the impression that the portable dumper idea was
> rejected mainly on the base that it is coded in C while a possible
> solution exists taht can be implemented in elisp.

Dumping is not just any optional feature, it's a feature without which
Emacs cannot be built, so there are additional considerations in that
case.

Re: Native display of line numbers

[Eli Zaretskii]

> From: Scott Jaderholm <jaderholm@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Sun, 18 Jun 2017 15:20:04 -0700
> 
> It would be nice to be able to display both absolute and relative line
> numbers at the same time, with each having their own face.

That sounds strange to me.  What is the use case for that?  Would a
key binding that would switch between absolute and relative numbers be
good enough for such a use case?

Re: Native display of line numbers

[Eli Zaretskii]

> Date: Sun, 18 Jun 2017 17:46:33 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > Date: Sun, 18 Jun 2017 10:44:36 +0200
> > From: martin rudalics <rudalics@gmx.at>
> > 
> > One problem I see is that once a window has been scrolled to the right,
> > it's not easy to auto-hscroll it back, at least with ‘truncate-lines’
> > non-nil.
> 
> Yes, truncated lines have a few bugs with this feature, I have a todo
> item to look into that.  Thanks for the test case.

Btw, the stuff that really bothers me are all those low-level
functions that depends on window geometry for measuring the text-area
width.  Line numbers take up some of that space, and it isn't clear to
me what that breaks.  Perhaps you could take a look at the relevant
functions?  We may need to provide a primitive which returns the width
taken by the line number display.

TIA

Re: Native display of line numbers

[Clément Pit-Claudel]

On 2017-06-18 16:48, Daniele Nicolodi wrote:
> On 18/06/17 14:04, Eli Zaretskii wrote:
>>> From: Daniele Nicolodi <daniele@grinta.net>
>>> Date: Sun, 18 Jun 2017 13:41:04 -0600
>>>
>>> I though there were am hard veto on the implementation of any new
>>> functionality in C code, because reasons.
>>
>> Evidently, this impression was based on some misunderstanding.  New
>> Emacs features are coded in C all the time, e.g. see the recently
>> added command replace-buffer-contents.
> 
> Evidently, I was under the impression that the portable dumper idea was
> rejected mainly on the base that it is coded in C while a possible
> solution exists taht can be implemented in elisp.

That's not how I remember it, at least.  IIUC, the debate was mostly about the data representation format for the dump file (C code, or ELisp).  The implementation of the dumper and loader was mostly C in both cases, although in the ELisp representation the loader was just the (existing) ELisp reader. Did I misunderstand?

Clément.

Re: Native display of line numbers

[Daniele Nicolodi]

On 18/06/17 20:31, Eli Zaretskii wrote:
>> From: Daniele Nicolodi <daniele@grinta.net>
>> Date: Sun, 18 Jun 2017 14:48:41 -0600
>>
>>> Evidently, this impression was based on some misunderstanding.  New
>>> Emacs features are coded in C all the time, e.g. see the recently
>>> added command replace-buffer-contents.
>>
>> Evidently, I was under the impression that the portable dumper idea was
>> rejected mainly on the base that it is coded in C while a possible
>> solution exists taht can be implemented in elisp.
> 
> Dumping is not just any optional feature, it's a feature without which
> Emacs cannot be built, so there are additional considerations in that
> case.

Just to be sure: are you saying that functionality can be implemented in
the Emacs C core as long as this is an optional and not essential?

Cheers,
Daniele

Re: Native display of line numbers

[Eli Zaretskii]

On June 19, 2017 5:44:11 AM GMT+03:00, "Clément Pit-Claudel" <cpitclaudel@gmail.com> wrote:
> On 2017-06-18 16:48, Daniele Nicolodi wrote:

> That's not how I remember it, at least.  IIUC, the debate was mostly
> about the data representation format for the dump file (C code, or
> ELisp).  The implementation of the dumper and loader was mostly C in
> both cases, although in the ELisp representation the loader was just
> the (existing) ELisp reader. Did I misunderstand?
> 
> Clément.

Ken's implementation of dumping is in loadup.el, so it is in Lisp.  The changes
in C are mostly to speed up loading .elc files and some auxiliary infrastructure.

Re: Native display of line numbers

[Clément Pit-Claudel]

On 2017-06-19 00:15, Eli Zaretskii wrote:
> On June 19, 2017 5:44:11 AM GMT+03:00, "Clément Pit-Claudel" <cpitclaudel@gmail.com> wrote:
>> On 2017-06-18 16:48, Daniele Nicolodi wrote:
> 
>> That's not how I remember it, at least.  IIUC, the debate was mostly
>> about the data representation format for the dump file (C code, or
>> ELisp).  The implementation of the dumper and loader was mostly C in
>> both cases, although in the ELisp representation the loader was just
>> the (existing) ELisp reader. Did I misunderstand?
>>
>> Clément.
> 
> Ken's implementation of dumping is in loadup.el, so it is in Lisp.  The changes
> in C are mostly to speed up loading .elc files and some auxiliary infrastructure.

Makes sense, thanks!

Re: Native display of line numbers

[Yuri Khan]

On Mon, Jun 19, 2017 at 2:00 AM, Eli Zaretskii <eliz@gnu.org> wrote:

>> Some of these attract to the buffer text more strongly than others.
>
> Yes, but why is that a problem?  And if some combinations are really
> too much, then are those combinations really that frequent that they
> should be source of a worry?  And if they are, how come this wasn't an
> issue until now?

Until now, there were two facilities (fringe and margin) and their
order was customizable via one boolean variable,
‘fringes-outside-margin’. By default, it is nil so fringes are inside
and thus closer to the text than line numbers displayed in the
margins.

How much is too much is subjective.

> OK, and what's your point?  That the line number display is not ideal?
> I agree, but I think the alternatives are much worse.  E.g., switching
> the order can only work on TTY frames and when the fringes are
> disabled,

I do not understand this limitation. Could you please elaborate?

> so it cannot be done by default, or we will have
> inconsistent behavior.

> I'm sure people who like line numbers will get
> used to the arrangement of indicators soon enough; I did.  Especially
> since long lines are rare in source code buffers, at least IME.

Depends on what we call long lines. I run Emacs in two windows
side-by-side on a 24″ monitor, so for me everything exceeding ≈100
columns is a long line. My teammates sometimes break this limit, and
some teams in the company I work for have a 120-column coding
standard. Whenever I need to read their code, I get annoyed at them;
ideally, my tool would help me cope with that annoyance, not
exacerbate it.

> Experience shows that using the margins for such pervasive modes is
> trouble in itself, because there are modes which want to use the
> margins for their own purposes.  We still don't have a satisfactory
> solution for those problems.

The problem here is that there isn’t a defined protocol for sharing
the margin. There was a discussion in 2015-12 on that matter.

https://lists.gnu.org/archive/html/emacs-devel/2015-12/msg00066.html

Re: Native display of line numbers

[Scott Jaderholm]

On Mon, Jun 19 2017,Eli Zaretskii wrote:

>> From: Scott Jaderholm <jaderholm@gmail.com> Cc: emacs-devel@gnu.org
>> Date: Sun, 18 Jun 2017 15:20:04 -0700
>> 
>> It would be nice to be able to display both absolute and relative line
>> numbers at the same time, with each having their own face.
>
> That sounds strange to me. What is the use case for that?

It's not that there's a unique use case when they're used together, but
that there are various independent use cases for absolute line numbers
and various independent use cases for relative line numbers, and a user
might want some from both sets at any time.

For example, relative line numbers are useful for counting items in a
list and prefixing movement/deletion/etc commands. Absolute line numbers
are useful for tracking down errors, context in the file, or
communicating a line. A user might want all of these things.

> Would a key binding that would switch between absolute and relative
> numbers be good enough for such a use case?

I think it would be unfortunate if that were required. For most of the
use cases for both modes it's nice to be able to see the numbers at a
glance without having to invoke a command first. If users were happy
pressing a key before seeing line numbers, then the performance when
scrolling wouldn't matter because the old modes could just be used on
demand.

Another way to think about it is it's nice to have more than one item in
a mode-line. It would be unfortunate if mode-lines could only display
buffer names and we had to press a key binding everytime we wanted to see
something else there.

Scott

Re: Native display of line numbers

[martin rudalics]

 > Btw, the stuff that really bothers me are all those low-level
 > functions that depends on window geometry for measuring the text-area
 > width.  Line numbers take up some of that space, and it isn't clear to
 > me what that breaks.  Perhaps you could take a look at the relevant
 > functions?  We may need to provide a primitive which returns the width
 > taken by the line number display.

If you intend to keep the current implementation, I see no need for such
a primitive.  The window code doesn't handle ‘line-prefix’ or
‘wrap-prefix’ specially either.  Things will get problematic as soon as
you want to display line numbers outside the fringes or margins.  But
IIUC you currently don't have any intentions to do that.

If someone wants the mouse to do something special on line numbers, then
coordinates_in_window would have to be amended appropriately.  Whether
we want to consult the current glyph matrix in that case or keep a LorR
bool + a line_number_display_width integer in the window structure is a
minor issue IMHO.  Maybe a boolean to turn off line numbers for a
specific window only would be useful.  This can be easily added later.

martin

Re: Native display of line numbers

[Eli Zaretskii]

> From: Daniele Nicolodi <daniele@grinta.net>
> Date: Sun, 18 Jun 2017 21:07:32 -0600
> 
> Just to be sure: are you saying that functionality can be implemented in
> the Emacs C core as long as this is an optional and not essential?

And as long as doing it in C (as opposed to in Lisp) is justified,
i.e. if a Lisp implementation is either impossible or very
inefficient.  AFAIK this has always been the rule, at least in recent
years.  There's no change here.

Re: Native display of line numbers

[Eli Zaretskii]

> Date: Mon, 19 Jun 2017 10:04:18 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: emacs-devel@gnu.org
> 
> If you intend to keep the current implementation, I see no need for such
> a primitive.  The window code doesn't handle ‘line-prefix’ or
> ‘wrap-prefix’ specially either.  Things will get problematic as soon as
> you want to display line numbers outside the fringes or margins.  But
> IIUC you currently don't have any intentions to do that.

Right.  Thanks, I was thinking along the same lines, but wasn't sure I
didn't miss anything.  I'm encouraged now.

Re: Native display of line numbers

[Eli Zaretskii]

> From: James Nguyen <jamesn@fastmail.com>
> Date: Sun, 18 Jun 2017 19:25:46 -0700
> Cc: Mathias Dahl <mathias.dahl@gmail.com>,
>  emacs-devel@gnu.org
> 
> 1. Overlays might mess with the line numbers.

Overlays or just company-mode and its likes?  If the former, can you
show a simple recipe to demonstrate the problems with overlays?

> Using company-mode along with display-line-numbers. The overlay gets a little
> janky and the line numbers disappear where the overlay shows up.
> 
> Here's a pic I found from reddit detailing the same thing.
> 
> https://i.imgur.com/qXSJDrv.png

Maybe one of the company-mode developers could look into this.

> 2. Haven't been able to reproduce it, but I was scrolling downwards with a Macbook
> Touchpad with relative numbers and the numbers kept toggling back to the absolute
> version. Scrolling up was fine.

Scrolling with what command(s)?

Thanks for the feedback.

Re: Native display of line numbers

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Mon, 19 Jun 2017 12:32:19 +0700
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> How much is too much is subjective.

Fair enough.

> > OK, and what's your point?  That the line number display is not ideal?
> > I agree, but I think the alternatives are much worse.  E.g., switching
> > the order can only work on TTY frames and when the fringes are
> > disabled,
> 
> I do not understand this limitation. Could you please elaborate?

Sure.  The basic restriction (well, unless the geometry of the display
canvas is redesigned) is that what is collectively called "display
elements" -- character glyphs, images, stretches of whitespace,
xwidgets, etc. -- can appear in one of 3 areas of the display: the
left margin, text area, and the right margin.  The order of these 3
areas is fixed, left to right (although one or both of the margins
could be empty).  Each one of the 3 areas is contiguous, so e.g. you
cannot place the fringe in the middle of the text area, as that will
disrupt layout calculations.

The line numbers in my implementation are in the text area, before the
actual line.  On TTY frames, the left-truncation indicator is also in
the text area before the actual line.  It is injected there by the
display engine in a way that is very similar to my implementation of
the line numbers.  So on TTY frames, I could in principle insert the
line number before the truncation indicator.  But that cannot be done
on GUI frames, because the indicator is on the fringe, and cannot be
moved to be to the right of the line numbers, as long as we want the
line numbers to be in the text area, not in the margin.

So if we want consistency between the GUI and TTY frames, the
left-truncation indicator should be to the left of the line numbers on
TTY frames as well.

> > I'm sure people who like line numbers will get
> > used to the arrangement of indicators soon enough; I did.  Especially
> > since long lines are rare in source code buffers, at least IME.
> 
> Depends on what we call long lines. I run Emacs in two windows
> side-by-side on a 24″ monitor, so for me everything exceeding ≈100
> columns is a long line. My teammates sometimes break this limit, and
> some teams in the company I work for have a 120-column coding
> standard.

IME, lines longer than 80 columns are frowned upon in many coding
standards.  It's certainly so in Emacs and on my daytime job.  And
even if such long lines are allowed, I presume most of the lines are
way shorter, at least in some popular languages.

I'm not saying long lines never happen, I'm saying this is a clear
80-20 situation, and IMO we should favor the majority.

> > Experience shows that using the margins for such pervasive modes is
> > trouble in itself, because there are modes which want to use the
> > margins for their own purposes.  We still don't have a satisfactory
> > solution for those problems.
> 
> The problem here is that there isn’t a defined protocol for sharing
> the margin. There was a discussion in 2015-12 on that matter.
> 
> https://lists.gnu.org/archive/html/emacs-devel/2015-12/msg00066.html

Indeed we discussed this more than once, but the problem is still
unsolved, and AFAIR we were unable to even reach a consensus, let
alone design the solution.  Which to me means the problem is really
hard to solve.  Working around hard problems is a good engineering
practice.

Re: Native display of line numbers

[James Nguyen]

>> Overlays or just company-mode and its likes?  If the former, can you
>> show a simple recipe to demonstrate the problems with overlays?

I’m not sure, but I included a snippet for company-mode.

#+begin_src emacs-lisp :tangle yes

  (let ((default-directory "~/.emacs.d/"))
    (normal-top-level-add-subdirs-to-load-path))

  ;; M-x list-packages U x to upgrade packages.
  (setq package-list '(diminish))

  ;; Disable in favor of `use-package'.
  (setq package-enable-at-startup nil)

  ;; Package Repositories
  (setq package-archives '(("melpa" . "https://melpa.org/packages/")
                           ("gnu" . "https://elpa.gnu.org/packages/")))

  ;; Activate all packages (in particular autoloads).
  (package-initialize)

  ;; Bootstrap `use-package'.
  (unless (package-installed-p 'use-package)
    (package-refresh-contents)
    (package-install 'use-package))

  (eval-when-compile
    (require 'use-package))
  (require 'diminish) ; for :diminish
  (require 'bind-key) ; for :bind

  ;; Install package if not existing.
  (setq use-package-always-ensure nil)

  ;; Check loading times with `use-package'.
  (setq use-package-verbose t)

  ;; Fetch the list of packages when unavailable.
  (when (not package-archive-contents)
    (package-refresh-contents))

  ;; Install any missing packages.
  (dolist (package package-list)
    (when (not (package-installed-p package))
      (package-install package)))

  (use-package company
    :ensure t
    :config
    (setq company-echo-delay 1)
    (setq company-minimum-prefix-length 1)
    (global-company-mode))

  (setq-default display-line-numbers 'relative)
  
  ;; Type a few characters to trigger autocompletion
#+end_src

>> Scrolling with what command(s)?

#+begin_src emacs-lisp :tangle yes
(setq scroll-margin 5
      scroll-step 1
      scroll-conservatively 10000
      scroll-preserve-screen-position 1)

(setq mouse-wheel-scroll-amount '(1))
(setq mouse-wheel-progressive-speed nil)
(setq mouse-wheel-follow-mouse 't)
(pixel-scroll-mode)
(setq-default display-line-numbers 'relative)

;; Emacs -Q
;; Visit a file like xdisp.c.
;; Scroll up and down with touchpad in the middle of the file.

#+end_src

Re: Native display of line numbers

[Stephen Leake]

Eli Zaretskii <eliz@gnu.org> writes:

> However, many users want line numbers to be displayed in Emacs.  I
> don't know why they want it, perhaps they were "spoiled" by other IDEs
> or something.

The only time I used line numbers in Emacs was to prepare a paper
printout for a code review; for that, line numbers are essential. Later,
I always did code reviews on a terminal, so line numbers were not
needed.

But it does raise the question; with the display engine line numbers be
printed if the buffer is printed?

-- 
-- Stephe

Re: Native display of line numbers

[Eli Zaretskii]

> From: Stephen Leake <stephen_leake@stephe-leake.org>
> Date: Mon, 19 Jun 2017 11:56:00 -0500
> 
> But it does raise the question; with the display engine line numbers be
> printed if the buffer is printed?

No, because they are not in buffer text.  Which line-numbering package
in Emacs can produce the line numbers in print?

Re: Native display of line numbers

[Alan Mackenzie]

Hello, Eli.

On Sat, Jun 17, 2017 at 18:12:00 +0300, Eli Zaretskii wrote:

[ .... ]

> So with that in mind, I came up with an implementation of a native
> display of line numbers.  You can find it in the scratch/line-numbers
> branch of the Emacs repository.  Compared with linum-mode,
> nlinum-mode, and other similar modes, it has the following main
> advantages:

>   . it works significantly faster (almost twice as fast as linum-mode,
>     50% faster that relative-line-numbers-mode)
>   . it doesn't use the display margins
>   . it works with R2L text, something the old modes never did

> The main features of the line-numbering modes are all supported by
> this new feature.

> Please give it a try and report any bugs you find.  I'm sure there
> will be quite a few bugs, given the sheer amount of display feature
> which could be affected, and which I didn't have time to test.

There's one other thing which surprises me, and apologies if somebody
else has already mentioned it and I've missed that post.  At least on a
Linux tty, one character position is "wasted" to the left of the line
numbers.  Just about everything else I use in this tty environment,
including the command line, and the emacs master, starts with the first
character of a line bang up against the edge of the screen.  So why is
this extra space put in?  Might this be a case for a user option?

[ .... ]

> TIA

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Native display of line numbers

[Stephen Leake]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stephen Leake <stephen_leake@stephe-leake.org>
>> Date: Mon, 19 Jun 2017 11:56:00 -0500
>> 
>> But it does raise the question; with the display engine line numbers be
>> printed if the buffer is printed?
>
> No, because they are not in buffer text.  Which line-numbering package
> in Emacs can produce the line numbers in print?

It was a long time ago; I may be misremembering what tools I used.

-- 
-- Stephe

Re: Native display of line numbers

[Eli Zaretskii]

> Date: Mon, 19 Jun 2017 18:39:45 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> There's one other thing which surprises me, and apologies if somebody
> else has already mentioned it and I've missed that post.  At least on a
> Linux tty, one character position is "wasted" to the left of the line
> numbers.  Just about everything else I use in this tty environment,
> including the command line, and the emacs master, starts with the first
> character of a line bang up against the edge of the screen.  So why is
> this extra space put in?

The reason is explained in the comments.  In a nutshell, it's a cheaty
solution for a problem for which I couldn't find a better one.  If I
ever will, the extra space will go away.  (I'm surprised that someone
could be sensitive to one less column with today's large screens,
especially after giving up several columns for the numbers.)

> Might this be a case for a user option?

No, sorry.

Re: Native display of line numbers

[Eli Zaretskii]

> From: Stephen Leake <stephen_leake@stephe-leake.org>
> Date: Mon, 19 Jun 2017 13:43:09 -0500
> 
> >> But it does raise the question; with the display engine line numbers be
> >> printed if the buffer is printed?
> >
> > No, because they are not in buffer text.  Which line-numbering package
> > in Emacs can produce the line numbers in print?
> 
> It was a long time ago; I may be misremembering what tools I used.

Could it be that you used ps-print with ps-line-number set?

Re: Native display of line numbers

[Alan Mackenzie]

Hello, Eli.

On Mon, Jun 19, 2017 at 22:28:41 +0300, Eli Zaretskii wrote:
> > Date: Mon, 19 Jun 2017 18:39:45 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > There's one other thing which surprises me, and apologies if somebody
> > else has already mentioned it and I've missed that post.  At least on a
> > Linux tty, one character position is "wasted" to the left of the line
> > numbers.  Just about everything else I use in this tty environment,
> > including the command line, and the emacs master, starts with the first
> > character of a line bang up against the edge of the screen.  So why is
> > this extra space put in?

> The reason is explained in the comments.  In a nutshell, it's a cheaty
> solution for a problem for which I couldn't find a better one.  If I
> ever will, the extra space will go away.

OK.

> (I'm surprised that someone could be sensitive to one less column with
> today's large screens, especially after giving up several columns for
> the numbers.)

My screen is 240 characters wide.  Split that into three follow-mode
windows, and those windows are 79, 79, 80 wide.  With much code being "a
bit less than 80" wide, that extra space might make for quite a few more
continued lines.

The extra space at the rim of the monitor does kind of stand out rather,
though.

> > Might this be a case for a user option?

> No, sorry.

OK.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Native display of line numbers

[Eli Zaretskii]

> Date: Mon, 19 Jun 2017 19:38:38 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > (I'm surprised that someone could be sensitive to one less column with
> > today's large screens, especially after giving up several columns for
> > the numbers.)
> 
> My screen is 240 characters wide.  Split that into three follow-mode
> windows, and those windows are 79, 79, 80 wide.  With much code being "a
> bit less than 80" wide, that extra space might make for quite a few more
> continued lines.

The line numbers are displayed using a distinct face, so you can
customize that face to use a smaller font and get back your extra
column, or at least part of it.

> The extra space at the rim of the monitor does kind of stand out rather,
> though.

I actually find numbers flushed all the way to the left uglier, but
that's me (and is not the reason why I usurped that column).

Re: Native display of line numbers

[Filipe Silva]

[-- Attachment #1: Type: text/plain, Size: 3844 bytes --]

Eli
​, thanks so much for your work on this. I means a lot to have this feature
implemented in the timeless editor.

I'm an evil-mode user and this is one of the features I miss most in vim:
relative line numbers. But let me be more clear:

Vim implements​ relative line numbers in a way that the "relativity" aspect
is based on the visible lines of the buffer.

This means that, for example, in an org-mode buffer, where you have a bunch
of lines collpsed, you would number those visible lines with numbers
relative to the line of point, and not based on the "real" relativity.

Why this is useful? because it gives vim/evil-mode users the power to
rapidly move through the visible lines in the window. If I want to jump to
a line in the buffer that I'm interested in, I just have to take a peek at
the relative number and then I know what to do. I just: 9k, to jump 9 lines
down. This is actually super powerful.

another very interesting use for this specific implementation of relative
line numbers is the remote copy feature of vim ex commands. A very common
operation: I'm in an empty line and I want to copy a line that is 17 lines
above the line where point is. Example: :-13y to copy the 13th line above
the line where point is. This is only the tip of the iceber. This has all
kinds of uses.

Also, implementing a toggle that would let me switch between this absolute
and relative line numbering would be beyond awesome.

Again, thanks for all your work in emacs.

Filipe

On Jun 17, 2017 12:12 PM, "Eli Zaretskii" <eliz@gnu.org> wrote:

> I generally consider display of line numbers for each line in the
> buffer un-Emacsy, something that came from the dark era when we needed
> to count lines to be able to tell the then existing editors something
> like "move down N lines, then DO SOMETHING".  Emacs pioneered today's
> world where all this is unnecessary, and the rest is history.
>
> However, many users want line numbers to be displayed in Emacs.  I
> don't know why they want it, perhaps they were "spoiled" by other IDEs
> or something.  In any case, given the popularity of the various add-on
> modes which insist on displaying line numbers using all kinds of
> tricks, I don't think we can ignore this tendency any longer, even if
> we agree that this is a disease.  The "epidemic" has spread too far
> and too wide for us to continue looking the other way.  And since
> Emacs doesn't make it easy for a Lisp program to invade the holy realm
> of redisplay, those modes use tricks that make Emacs slower and
> frequently interfere with other packages.  They also make demands on
> the display engine that make Emacs harder to develop and maintain.
>
> So with that in mind, I came up with an implementation of a native
> display of line numbers.  You can find it in the scratch/line-numbers
> branch of the Emacs repository.  Compared with linum-mode,
> nlinum-mode, and other similar modes, it has the following main
> advantages:
>
>   . it works significantly faster (almost twice as fast as linum-mode,
>     50% faster that relative-line-numbers-mode)
>   . it doesn't use the display margins
>   . it works with R2L text, something the old modes never did
>
> The main features of the line-numbering modes are all supported by
> this new feature.
>
> Please give it a try and report any bugs you find.  I'm sure there
> will be quite a few bugs, given the sheer amount of display feature
> which could be affected, and which I didn't have time to test.
>
> Once the flood of serious bug reports dries out, I will look into
> merging this to master.  If, miraculously, no such flood arrives, I
> will merge in a couple of weeks.  When that happens, we will declare
> all the other modes which do the same job deprecated.
>
> TIA
>
>

[-- Attachment #2: Type: text/html, Size: 5093 bytes --]

Re: Native display of line numbers

[Eli Zaretskii]

> From: Filipe Silva <filipe.silva@gmail.com>
> Date: Thu, 22 Jun 2017 12:02:55 -0300
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> Eli
> ​, thanks so much for your work on this. I means a lot to have this feature implemented in the timeless editor.
> 
> I'm an evil-mode user and this is one of the features I miss most in vim: relative line numbers. But let me be
> more clear:
> 
> Vim implements​ relative line numbers in a way that the "relativity" aspect is based on the visible lines of the
> buffer.
> 
> This means that, for example, in an org-mode buffer, where you have a bunch of lines collpsed, you would
> number those visible lines with numbers relative to the line of point, and not based on the "real" relativity. 

Yes, this was already requested.  I understand that there are no Emacs
packages that offer this feature right now, is that right?

Anyway, implementing this will need to code a whole different method
of counting lines (the current branch just reuses the same code which
produces the line numbers in the mode line), so I will need to
experiment to see if it can be implemented fast enough to avoid
slowing down redisplay, which is already slower in folded buffers.
IOW, this feature will take some time to implement correctly.

Thanks for the feedback.

Re: Native display of line numbers

[Filipe Silva]

[-- Attachment #1: Type: text/plain, Size: 1739 bytes --]

Hi Eli, I understand, thank you.

the only package that tries to do what I have just describe is an abandoned
package from github user fanael. It has bugs and performance issues that
render it unusable.

here is the link: https://github.com/Fanael/relative-line-numbers/issues/3

On Jun 22, 2017 12:38 PM, "Eli Zaretskii" <eliz@gnu.org> wrote:

> > From: Filipe Silva <filipe.silva@gmail.com>
> > Date: Thu, 22 Jun 2017 12:02:55 -0300
> > Cc: Emacs developers <emacs-devel@gnu.org>
> >
> > Eli
> > ​, thanks so much for your work on this. I means a lot to have this
> feature implemented in the timeless editor.
> >
> > I'm an evil-mode user and this is one of the features I miss most in
> vim: relative line numbers. But let me be
> > more clear:
> >
> > Vim implements​ relative line numbers in a way that the "relativity"
> aspect is based on the visible lines of the
> > buffer.
> >
> > This means that, for example, in an org-mode buffer, where you have a
> bunch of lines collpsed, you would
> > number those visible lines with numbers relative to the line of point,
> and not based on the "real" relativity.
>
> Yes, this was already requested.  I understand that there are no Emacs
> packages that offer this feature right now, is that right?
>
> Anyway, implementing this will need to code a whole different method
> of counting lines (the current branch just reuses the same code which
> produces the line numbers in the mode line), so I will need to
> experiment to see if it can be implemented fast enough to avoid
> slowing down redisplay, which is already slower in folded buffers.
> IOW, this feature will take some time to implement correctly.
>
> Thanks for the feedback.
>

[-- Attachment #2: Type: text/html, Size: 2373 bytes --]

Re: Native display of line numbers

[Yuri Khan]

On Thu, Jun 22, 2017 at 10:02 PM, Filipe Silva <filipe.silva@gmail.com> wrote:


> Vim implements relative line numbers in a way that the "relativity" aspect
> is based on the visible lines of the buffer.

> Why this is useful? because it gives vim/evil-mode users the power to
> rapidly move through the visible lines in the window. If I want to jump to a
> line in the buffer that I'm interested in, I just have to take a peek at the
> relative number and then I know what to do. I just: 9k, to jump 9 lines
> down. This is actually super powerful.

What about deleting 9 lines? Does deletion work in terms of visual or
logical lines in vim?

In Emacs, as far as I can tell, visual line movement only affects
movement, killing still works by logical lines.

That may mean you’d need relative visual line numbers when you are
going to press a movement (<up>/<down>/C-n/C-p) key, and relative
logical line numbers when you are going to press a kill-line key
(<C-S-backspace> or C-k).

Re: Native display of line numbers

[Stephen Berman]

On Thu, 22 Jun 2017 23:27:08 +0700 Yuri Khan <yuri.v.khan@gmail.com> wrote:

> In Emacs, as far as I can tell, visual line movement only affects
> movement, killing still works by logical lines.

Surprise:

  C-k runs the command kill-visual-line (found in visual-line-mode-map), which
  is an interactive compiled Lisp function in ‘simple.el’.
  
  It is bound to C-k, <deleteline>.
  
  (kill-visual-line &optional ARG)
  
  Kill the rest of the visual line.
  With prefix argument ARG, kill that many visual lines from point.
  If ARG is negative, kill visual lines backward.
  If ARG is zero, kill the text before point on the current visual
  line.
  [...]

Steve Berman

Re: Native display of line numbers

[Filipe Silva]

[-- Attachment #1: Type: text/plain, Size: 1742 bytes --]

when deleting 9 lines below with d9j, vim works in terms of visual lines.

so if you have, between those visual lines, a line that represents a
collapsed org-mode buffer that has a thousand lines beneath it, it would
kill those lines in the process.

That's what I'd expect. I'm killing what I'm seeing. I know that it is a
collapsed org-mode buffer bullet. I'm deleting 9 lines below of the current
line. I want that org-mode buffer collapsed buffer to be killed to.

If you want to delete the real lines, just expand the bullet.

as I said, you can see that this is hugely powerful.



On Thu, Jun 22, 2017 at 1:27 PM, Yuri Khan <yuri.v.khan@gmail.com> wrote:

> On Thu, Jun 22, 2017 at 10:02 PM, Filipe Silva <filipe.silva@gmail.com>
> wrote:
>
>
> > Vim implements relative line numbers in a way that the "relativity"
> aspect
> > is based on the visible lines of the buffer.
>
> > Why this is useful? because it gives vim/evil-mode users the power to
> > rapidly move through the visible lines in the window. If I want to jump
> to a
> > line in the buffer that I'm interested in, I just have to take a peek at
> the
> > relative number and then I know what to do. I just: 9k, to jump 9 lines
> > down. This is actually super powerful.
>
> What about deleting 9 lines? Does deletion work in terms of visual or
> logical lines in vim?
>
> In Emacs, as far as I can tell, visual line movement only affects
> movement, killing still works by logical lines.
>
> That may mean you’d need relative visual line numbers when you are
> going to press a movement (<up>/<down>/C-n/C-p) key, and relative
> logical line numbers when you are going to press a kill-line key
> (<C-S-backspace> or C-k).
>

[-- Attachment #2: Type: text/html, Size: 2633 bytes --]

Re: Native display of line numbers

[Filipe Silva]

[-- Attachment #1: Type: text/plain, Size: 2279 bytes --]

by the way, that's the way emacs with evil-mode handles things right now.

d9j will delete every VISUAL line, and if any of those visual lines are
actually collapsed, the entire set of real lines will be killed in the
process.

Exciting stuff. now we just need that relative line numbers feature out to
be able to shred text in emacs with even more power.

gogo Eli! :)

Filipe


On Fri, Jun 23, 2017 at 8:10 AM, Filipe Silva <filipe.silva@gmail.com>
wrote:

> when deleting 9 lines below with d9j, vim works in terms of visual lines.
>
> so if you have, between those visual lines, a line that represents a
> collapsed org-mode buffer that has a thousand lines beneath it, it would
> kill those lines in the process.
>
> That's what I'd expect. I'm killing what I'm seeing. I know that it is a
> collapsed org-mode buffer bullet. I'm deleting 9 lines below of the current
> line. I want that org-mode buffer collapsed buffer to be killed to.
>
> If you want to delete the real lines, just expand the bullet.
>
> as I said, you can see that this is hugely powerful.
>
>
>
> On Thu, Jun 22, 2017 at 1:27 PM, Yuri Khan <yuri.v.khan@gmail.com> wrote:
>
>> On Thu, Jun 22, 2017 at 10:02 PM, Filipe Silva <filipe.silva@gmail.com>
>> wrote:
>>
>>
>> > Vim implements relative line numbers in a way that the "relativity"
>> aspect
>> > is based on the visible lines of the buffer.
>>
>> > Why this is useful? because it gives vim/evil-mode users the power to
>> > rapidly move through the visible lines in the window. If I want to jump
>> to a
>> > line in the buffer that I'm interested in, I just have to take a peek
>> at the
>> > relative number and then I know what to do. I just: 9k, to jump 9 lines
>> > down. This is actually super powerful.
>>
>> What about deleting 9 lines? Does deletion work in terms of visual or
>> logical lines in vim?
>>
>> In Emacs, as far as I can tell, visual line movement only affects
>> movement, killing still works by logical lines.
>>
>> That may mean you’d need relative visual line numbers when you are
>> going to press a movement (<up>/<down>/C-n/C-p) key, and relative
>> logical line numbers when you are going to press a kill-line key
>> (<C-S-backspace> or C-k).
>>
>
>

[-- Attachment #2: Type: text/html, Size: 3922 bytes --]

Re: Native display of line numbers

[Stefan Monnier]

> Anyway, implementing this will need to code a whole different method
> of counting lines (the current branch just reuses the same code which
> produces the line numbers in the mode line), so I will need to
> experiment to see if it can be implemented fast enough to avoid
> slowing down redisplay, which is already slower in folded buffers.

Indeed, to make it fast enough it probably needs to count lines using
the matrices rather than the buffer.  That should actually make it
faster than absolute line numbers (at least in large buffers).


        Stefan

Re: Native display of line numbers

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 23 Jun 2017 12:23:06 -0400
> 
> > Anyway, implementing this will need to code a whole different method
> > of counting lines (the current branch just reuses the same code which
> > produces the line numbers in the mode line), so I will need to
> > experiment to see if it can be implemented fast enough to avoid
> > slowing down redisplay, which is already slower in folded buffers.
> 
> Indeed, to make it fast enough it probably needs to count lines using
> the matrices rather than the buffer.

No, I cannot use the glyph matrices, because the line numbers are
generated when the glyph matrix is created, and because the previous
matrix cannot be trusted in general.

I need to use the move_it_in_display_line_to and its ilk instead.

> That should actually make it faster than absolute line numbers (at
> least in large buffers).

I'm not sure.  I actually fear it's the other way around, because
counting logical lines is implemented by fast code using memchr,
whereas move_it_in_display_line_to must move one character at a time.
But it could well be that this is fast enough, especially since
relative line numbers never need us to go more than one window-full
away.

Re: Native display of line numbers

[Stefan Monnier]

>> Indeed, to make it fast enough it probably needs to count lines using
>> the matrices rather than the buffer.
> No, I cannot use the glyph matrices, because the line numbers are
> generated when the glyph matrix is created, and because the previous
> matrix cannot be trusted in general.

Can't you fill the glyph matrix with some filler while building the
matrix and at the end go back to put the line numbers?

> I need to use the move_it_in_display_line_to and its ilk instead.

That will make it costly, indeed.


        Stefan

Re: Native display of line numbers

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 23 Jun 2017 17:24:45 -0400
> 
> >> Indeed, to make it fast enough it probably needs to count lines using
> >> the matrices rather than the buffer.
> > No, I cannot use the glyph matrices, because the line numbers are
> > generated when the glyph matrix is created, and because the previous
> > matrix cannot be trusted in general.
> 
> Can't you fill the glyph matrix with some filler while building the
> matrix and at the end go back to put the line numbers?

That'd be problematic, because the only interpretation of "at the end"
I can come up with is "just before calling update_frame", since there
are a lot of shortcuts in the display engine which all lead to that
point.

Doing this at that point would mean potentially invalidating the
decisions already made by the display engine during its traversal of
the window tree.  E.g., screen lines that seemed to be unchanged will
now become changed due to changes in line numbers.  So this would
require an immediate second redisplay cycle, which runs afoul of my
attempt to speed up redisplay with line numbers.

> > I need to use the move_it_in_display_line_to and its ilk instead.
> 
> That will make it costly, indeed.

We shall see.  Every "normal" redisplay already calls these functions
for movement within the window limits, so it cannot be too slow.

Re: Native display of line numbers

[Eli Zaretskii]

> Date: Sun, 18 Jun 2017 17:54:31 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > It is nice to have native line numbers. They work with a non-default
> > background, correctly handle line wrapping, and even when their face
> > is customized to a smaller size. (In a larger size, their tops get
> > truncated, but that’s firmly in the “don’t to that, then” territory.)
> 
> Hmm... that ought to work.  Something's amiss, I'll take a look.

A bug, for sure.  Now fixed (but not pushed yet).