Native display of line numbers, improved

Native display of line numbers, improved

[Eli Zaretskii]

OK, I've updated the scratch/line-numbers branch with several bugfixes
and some new features.

All the bugs reported till now are fixed, with the sole exception of
truncated-lines display.  The latter behaves better now (in
particular, the funny problem reported by Martin, whereby you couldn't
get to the line beginning, is gone), but there are still issues with
hscrolling lines with TABs; I will try to fix those later.  The tricky
problems reported by Alan for Follow mode are also solved (relative
line numbers are now local to each window under Follow mode).

I fixed the issue with TAB stops, but only for the line-number
display, leaving alone other similar issues, like with line-prefix.

I added the features requested by several people, including relative
numbers with current line's number absolute, a separate face for
displaying the current line, and the display-line-numbers-disable
property for company-mode and its ilk.

The only requested feature that remains unimplemented is relative line
numbers counted visually.  The reason is that I'm not sure I
understand the requirements (and also not sure whether people who
asked for that have thought that through).  I will post a separate
message about that.

Comments and bug reports are welcome.  Apart of fixing bugs and
perhaps implementing the visual line counting, the only changes I plan
to commit before landing this on master is proper documentation in the
2 manuals.  Otherwise, the feature is complete from my POV, so here's
your chance to give it a ride before it lands.

Enjoy.

Re: Native display of line numbers, improved

[Clément Pit-Claudel]

On 2017-06-24 13:27, Eli Zaretskii wrote:
> Otherwise, the feature is complete from my POV, so here's
> your chance to give it a ride before it lands.

Wonderful job, as always :)

Re: Native display of line numbers, improved

[Eli Zaretskii]

> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Sat, 24 Jun 2017 14:40:21 -0400
> 
> Wonderful job, as always :)

Thanks.

Re: Native display of line numbers, improved

[Stephen Berman]

On Sat, 24 Jun 2017 20:27:07 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

> OK, I've updated the scratch/line-numbers branch with several bugfixes
> and some new features.
[...]
> I added the features requested by several people, including relative
> numbers with current line's number absolute, a separate face for
> displaying the current line

I notice that text-scale-adjust correctly changes the size of the line
numbers, except for that of the current line when the face
line-number-current-line has been changed from the default.  I assume
this is not intended (it results is misalignment between the current
line and the others).

Steve Berman

Re: Native display of line numbers, improved

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: emacs-devel@gnu.org
> Date: Sat, 24 Jun 2017 22:53:01 +0200
> 
> I notice that text-scale-adjust correctly changes the size of the line
> numbers, except for that of the current line when the face
> line-number-current-line has been changed from the default.

How did you change the line-number-current-line face?  If I just set
its foreground to a distinct value, text-scale-adjust changes the
sizes of all the line numbers, including that of the current line.

Maybe you changed the face with defface, in which case you should keep
the :inherit part, because AFAIK text-scale-adjust doesn't scale every
face, only some of them and those which inherit from those few.

Re: Native display of line numbers, improved

[Stephen Berman]

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

On Sun, 25 Jun 2017 17:07:34 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: emacs-devel@gnu.org
>> Date: Sat, 24 Jun 2017 22:53:01 +0200
>> 
>> I notice that text-scale-adjust correctly changes the size of the line
>> numbers, except for that of the current line when the face
>> line-number-current-line has been changed from the default.
>
> How did you change the line-number-current-line face?  If I just set
> its foreground to a distinct value, text-scale-adjust changes the
> sizes of all the line numbers, including that of the current line.
>
> Maybe you changed the face with defface, in which case you should keep
> the :inherit part, because AFAIK text-scale-adjust doesn't scale every
> face, only some of them and those which inherit from those few.

I used the Customize interface and kept :inherit.  Here's a screenshot
showing what I did and the effect:


[-- Attachment #2: line-number-current-line.png --]
[-- Type: image/png, Size: 24121 bytes --]

[-- Attachment #3: Type: text/plain, Size: 14 bytes --]


Steve Berman

Re: Native display of line numbers, improved

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: emacs-devel@gnu.org
> Date: Sun, 25 Jun 2017 16:34:36 +0200
> 
> > Maybe you changed the face with defface, in which case you should keep
> > the :inherit part, because AFAIK text-scale-adjust doesn't scale every
> > face, only some of them and those which inherit from those few.
> 
> I used the Customize interface and kept :inherit.  Here's a screenshot
> showing what I did and the effect:

This shows your face inherits from font-lock-comment-face.  It should
inherit from line-number instead.  Or from the default face.  When I
do one of those, the scaling works as you expected.

Re: Native display of line numbers, improved

[Stephen Berman]

On Sun, 25 Jun 2017 18:10:10 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: emacs-devel@gnu.org
>> Date: Sun, 25 Jun 2017 16:34:36 +0200
>> 
>> > Maybe you changed the face with defface, in which case you should keep
>> > the :inherit part, because AFAIK text-scale-adjust doesn't scale every
>> > face, only some of them and those which inherit from those few.
>> 
>> I used the Customize interface and kept :inherit.  Here's a screenshot
>> showing what I did and the effect:
>
> This shows your face inherits from font-lock-comment-face.  It should
> inherit from line-number instead.  Or from the default face.  When I
> do one of those, the scaling works as you expected.

Got it, thanks.  Is this documented?  I just looked again at the
references to text-scale-adjust and face customization in the Emacs user
manual and the sections on face attributes and face remapping in the
Elisp manual, and saw nothing from which I could infer the correct
procedure in this case (though the doc of face remapping is complicated,
so perhaps I missed or misunderstood the relevant information).

Steve Berman

Re: Native display of line numbers, improved

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: emacs-devel@gnu.org
> Date: Sun, 25 Jun 2017 17:41:38 +0200
> 
> > This shows your face inherits from font-lock-comment-face.  It should
> > inherit from line-number instead.  Or from the default face.  When I
> > do one of those, the scaling works as you expected.
> 
> Got it, thanks.  Is this documented?

Probably not.  And I'm not really sure how to document this in a way
that's useful.

In a nutshell, support for face remapping needs to be explicitly coded
where we want it, and AFAIK we only coded that in a few places which
were reported as bugs.  The fact that the face needs to inherit from
'default' is something I know only from personal experience.  In
particular, Customize somehow tends to break face remapping, unless
the inheritance keeps it from doing that.  Maybe someone who knows
more about faces and their customizations could chime in.

Re: Native display of line numbers, improved

[Stephen Berman]

On Sun, 25 Jun 2017 19:02:54 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: emacs-devel@gnu.org
>> Date: Sun, 25 Jun 2017 17:41:38 +0200
>> 
>> > This shows your face inherits from font-lock-comment-face.  It should
>> > inherit from line-number instead.  Or from the default face.  When I
>> > do one of those, the scaling works as you expected.
>> 
>> Got it, thanks.  Is this documented?
>
> Probably not.  And I'm not really sure how to document this in a way
> that's useful.
>
> In a nutshell, support for face remapping needs to be explicitly coded
> where we want it, and AFAIK we only coded that in a few places which
> were reported as bugs.  The fact that the face needs to inherit from
> 'default' is something I know only from personal experience.  In
> particular, Customize somehow tends to break face remapping, unless
> the inheritance keeps it from doing that.  Maybe someone who knows
> more about faces and their customizations could chime in.

I hope so.  It would be helpful to have clear guidelines, since faces
are probably one of the most frequently customized features in Emacs.

Steve Berman 

Re: Native display of line numbers, improved

[Stephen Berman]

On Sat, 24 Jun 2017 20:27:07 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

> OK, I've updated the scratch/line-numbers branch with several bugfixes
> and some new features.
[...]
> Comments and bug reports are welcome.  Apart of fixing bugs and
> perhaps implementing the visual line counting, the only changes I plan
> to commit before landing this on master is proper documentation in the
> 2 manuals.  Otherwise, the feature is complete from my POV, so here's
> your chance to give it a ride before it lands.

When the buffer ends with a newline and point is on it, no line number
is displayed on the left, though with line-number-mode enabled the mode
line does display the line number.  Also, with display-line-numbers set
to 'relative, it looks a bit odd to see relative numbering starting
above an empty unnumbered line.

Steve Berman

Re: Native display of line numbers, improved

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: emacs-devel@gnu.org
> Date: Sat, 24 Jun 2017 23:23:15 +0200
> 
> When the buffer ends with a newline and point is on it, no line number
> is displayed on the left, though with line-number-mode enabled the mode
> line does display the line number.

By "point is on it", I guess you mean point is at EOB, i.e. beyond the
last character position?  Because otherwise, I don't think I see what
you describe.

If this is about point at EOB, then this is the intended behavior: the
"line" where we position cursor in that case doesn't exist, so it
would be IMO incorrect to count it.  I'd prefer to leave the code
simple, without all kinds of subtleties whose sole purpose is to add
minor aesthetic sugar.

> Also, with display-line-numbers set to 'relative, it looks a bit odd
> to see relative numbering starting above an empty unnumbered line.

Nothing one cannot get used to, I think.

Thanks for the feedback.

Re: Native display of line numbers, improved

[Stephen Berman]

On Sun, 25 Jun 2017 17:03:30 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: emacs-devel@gnu.org
>> Date: Sat, 24 Jun 2017 23:23:15 +0200
>> 
>> When the buffer ends with a newline and point is on it, no line number
>> is displayed on the left, though with line-number-mode enabled the mode
>> line does display the line number.
>
> By "point is on it", I guess you mean point is at EOB, i.e. beyond the
> last character position?  Because otherwise, I don't think I see what
> you describe.

Yes, I meant at EOB.

> If this is about point at EOB, then this is the intended behavior: the
> "line" where we position cursor in that case doesn't exist, so it
> would be IMO incorrect to count it.  

By that reasoning, line-number-mode (the %l construct) should be changed
so as not to display a number when point is at EOB.  Perhaps it should
display "EOB" or "END" instead.

>                                      I'd prefer to leave the code
> simple, without all kinds of subtleties whose sole purpose is to add
> minor aesthetic sugar.

It's not a big deal for sure, though it seems at first sight unintuitive
that if the buffer ends with a sequence of newlines, all but the last
will be numbered (especially when the last one is also numbered in the
mode line).

Steve Berman

Re: Native display of line numbers, improved

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: emacs-devel@gnu.org
> Date: Sun, 25 Jun 2017 16:34:01 +0200
> 
> >                                      I'd prefer to leave the code
> > simple, without all kinds of subtleties whose sole purpose is to add
> > minor aesthetic sugar.
> 
> It's not a big deal for sure, though it seems at first sight unintuitive
> that if the buffer ends with a sequence of newlines, all but the last
> will be numbered (especially when the last one is also numbered in the
> mode line).

Well, if you turn on indicate-empty-lines, that last "line" will be
clearly indicated as empty.

Anyway, let's see how many people are annoyed by this before making a
decision.

line-number-mode at EOB (was: Native display of line numbers, improved)

[Stephen Berman]

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

On Sun, 25 Jun 2017 16:34:01 +0200 Stephen Berman <stephen.berman@gmx.net> wrote:

> On Sun, 25 Jun 2017 17:03:30 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
>
>>> From: Stephen Berman <stephen.berman@gmx.net>
>>> Cc: emacs-devel@gnu.org
>>> Date: Sat, 24 Jun 2017 23:23:15 +0200
>>> 
>>> When the buffer ends with a newline and point is on it, no line number
>>> is displayed on the left, though with line-number-mode enabled the mode
>>> line does display the line number.
>>
>> By "point is on it", I guess you mean point is at EOB, i.e. beyond the
>> last character position?  Because otherwise, I don't think I see what
>> you describe.
>
> Yes, I meant at EOB.
>
>> If this is about point at EOB, then this is the intended behavior: the
>> "line" where we position cursor in that case doesn't exist, so it
>> would be IMO incorrect to count it.  
>
> By that reasoning, line-number-mode (the %l construct) should be changed
> so as not to display a number when point is at EOB.  Perhaps it should
> display "EOB" or "END" instead.

I attempted to implement this change in the mode line display (see
attached patch) and the result, while admittedly only "minor aesthetic
sugar", seems to me not too bad: it makes line-number-mode consistent
not only with vertically displayed line numbers but also with
`count-words-region' (and hence with `count-lines').  What do others
think?

If this change is accepted, then the command `what-line' should probably
also be changed to return "EOB" at EOB.  (Such a change makes sense even
if line-number-mode is not changed, since it seems odd that e.g. in the
standard *scratch* buffer `C-x h M-=' reports "Region has 3 lines..."
while calling `what-line' at EOB reports "Line 4".)

Steve Berman



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: line-number-mode at EOB patch --]
[-- Type: text/x-patch, Size: 2106 bytes --]

diff --git a/lisp/bindings.el b/lisp/bindings.el
index be44b45136..4d4411e55d 100644
--- a/lisp/bindings.el
+++ b/lisp/bindings.el
@@ -415,8 +415,8 @@ mode-line-position
               'mouse-face 'mode-line-highlight
               'help-echo "Line number and Column number\n\
 mouse-1: Display Line and Column Mode Menu")))
-       (6 ,(propertize
-	    " L%l"
+       (6 (:propertize
+	    (:eval (if (eobp) " %l" " L%l"))
 	    'local-map mode-line-column-line-number-mode-map
 	    'mouse-face 'mode-line-highlight
 	    'help-echo "Line Number\n\
diff --git a/src/xdisp.c b/src/xdisp.c
index 2aceb89c00..600fad0100 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -11579,14 +11579,19 @@ window_buffer_changed (struct window *w)
   return (BUF_SAVE_MODIFF (b) < BUF_MODIFF (b)) != w->last_had_star;
 }
 
-/* True if W has %c or %C in its mode line and mode line should be updated.  */
+/* True if W has %c or %C in its mode line and mode line should be
+   updated. or if W has %l in its mode line and point has moved either
+   to or away from EOB.  */
 
 static bool
 mode_line_update_needed (struct window *w)
 {
-  return (w->column_number_displayed != -1
-	  && !(PT == w->last_point && !window_outdated (w))
-	  && (w->column_number_displayed != current_column ()));
+  return ((w->column_number_displayed != -1
+	   && !(PT == w->last_point && !window_outdated (w))
+	   && (w->column_number_displayed != current_column ()))
+	  || (line_number_displayed
+	      && ((ZV == w->last_point && PT != ZV)
+		  || (ZV != w->last_point && PT == ZV))));
 }
 
 /* True if window start of W is frozen and may not be changed during
@@ -24395,8 +24400,13 @@ decode_mode_spec (struct window *w, register int c, int field_width,
 	line_number_displayed = true;
 
 	/* Make the string to show.  */
-	pint2str (decode_mode_spec_buf, width, topline + nlines);
-	return decode_mode_spec_buf;
+	if (PT == BUF_ZV (b))
+	  return "EOB";
+	else
+	  {
+	    pint2str (decode_mode_spec_buf, width, topline + nlines);
+	    return decode_mode_spec_buf;
+	  }
     no_value:
         {
 	  char *p = decode_mode_spec_buf;

Re: line-number-mode at EOB

[Stefan Monnier]

> If this change is accepted, then the command `what-line' should probably
> also be changed to return "EOB" at EOB.  (Such a change makes sense even

This seems rather undesirable (same for the %l change to display EOB
rather than the line number).


        Stefan

Re: line-number-mode at EOB

[Stephen Berman]

On Tue, 18 Jul 2017 00:16:34 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>> If this change is accepted, then the command `what-line' should probably
>> also be changed to return "EOB" at EOB.  (Such a change makes sense even
>
> This seems rather undesirable (same for the %l change to display EOB
> rather than the line number).

Why (in both cases)?  Does it cause some misbehavior or is it otherwise
problematic?

Steve Berman

Re: line-number-mode at EOB

[Stefan Monnier]

>>> If this change is accepted, then the command `what-line' should probably
>>> also be changed to return "EOB" at EOB.  (Such a change makes sense even
>> This seems rather undesirable (same for the %l change to display EOB
>> rather than the line number).
> Why (in both cases)?  Does it cause some misbehavior or is it otherwise
> problematic?

Because it gives less information, IMO.  I think if we want to make
things consistent with the display-line-numbers, then it's
display-line-numbers which should be changed to also display the number
on the "non-existing" line after a final LF.  If that's too difficult,
then I prefer to keep it as a wishitem and live with the inconsistency
in the mean time.


        Stefan

Re: line-number-mode at EOB

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Tue, 18 Jul 2017 10:30:36 -0400
> 
> I think if we want to make things consistent with the
> display-line-numbers, then it's display-line-numbers which should be
> changed to also display the number on the "non-existing" line after
> a final LF.

But there's no line there.  Why should we have a number where there's
no line?

> If that's too difficult

It's not too easy, because that line is identical to all the rest
below it, as far as the display engine is concerned: they are all "at
EOB".

Re: line-number-mode at EOB

[Stefan Monnier]

>> I think if we want to make things consistent with the
>> display-line-numbers, then it's display-line-numbers which should be
>> changed to also display the number on the "non-existing" line after
>> a final LF.
> But there's no line there.

That's a philosophical opinion.
There's enough of a line to display a cursor, apparently.

> Why should we have a number where there's no line?

Because that's what some users expect.
Evidence of this includes the fact that it has been requested for linum,
for nlinum, for display-line-numbers.

I said "some" above because I don't know which proportion of users
expect this behavior.  My guess is that it's closer to "most", but since
I'm among those users, my impression is probably skewed.

Evidence suggests those users can live with the current lack of number
on that non-existing line, so it's not terribly important to fix (which
is also why I haven't bothered to try and change nlinum.el to display
that extra line-number).

But I don't think it warrants promoting this behavior to a feature.


        Stefan

Re: line-number-mode at EOB

[Paul Eggert]

On 07/18/2017 08:04 AM, Stefan Monnier wrote:
>> But there's no line there.
> That's a philosophical opinion.
> There's enough of a line to display a cursor, apparently.
>
More important, it's enough of a line so that (replace-regexp "^" "X") 
inserts three "X"s in a 2-line buffer. Which is something that has 
*always* annoyed me. Putting a line number after the last line would be 
almost as annoying.

Re: line-number-mode at EOB

[Stephen Berman]

On Thu, 20 Jul 2017 13:25:15 -0700 Paul Eggert <eggert@cs.ucla.edu> wrote:

> On 07/18/2017 08:04 AM, Stefan Monnier wrote:
>>> But there's no line there.
>> That's a philosophical opinion.
>> There's enough of a line to display a cursor, apparently.
>>
> More important, it's enough of a line so that (replace-regexp "^" "X") inserts
> three "X"s in a 2-line buffer.

Why doesn't this also happen with (replace-regexp "$" "X"), although
both (looking-at "^$") and (looking-at "$") return t at EOB (preceded by
a newline)?

Steve Berman

Re: line-number-mode at EOB

[Paul Eggert]

On 07/20/2017 01:43 PM, Stephen Berman wrote:
>> More important, it's enough of a line so that (replace-regexp "^" "X") inserts
>> three "X"s in a 2-line buffer.
> Why doesn't this also happen with (replace-regexp "$" "X"), although
> both (looking-at "^$") and (looking-at "$") return t at EOB (preceded by
> a newline)?

Sorry, haven't a clue. That part of Emacs has never made sense to me.

Re: line-number-mode at EOB

[Stephen Berman]

On Thu, 20 Jul 2017 14:19:41 -0700 Paul Eggert <eggert@cs.ucla.edu> wrote:

> On 07/20/2017 01:43 PM, Stephen Berman wrote:
>>> More important, it's enough of a line so that (replace-regexp "^" "X") inserts
>>> three "X"s in a 2-line buffer.
>> Why doesn't this also happen with (replace-regexp "$" "X"), although
>> both (looking-at "^$") and (looking-at "$") return t at EOB (preceded by
>> a newline)?
>
> Sorry, haven't a clue. That part of Emacs has never made sense to me.

Such an apparent inconsistency seems like a bug, but maybe there's a
good reason for it...

Steve Berman

Re: line-number-mode at EOB (was: Native display of line numbers, improved)

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: emacs-devel@gnu.org
> Date: Tue, 18 Jul 2017 00:20:10 +0200
> 
> > By that reasoning, line-number-mode (the %l construct) should be changed
> > so as not to display a number when point is at EOB.  Perhaps it should
> > display "EOB" or "END" instead.
> 
> I attempted to implement this change in the mode line display (see
> attached patch) and the result, while admittedly only "minor aesthetic
> sugar", seems to me not too bad: it makes line-number-mode consistent
> not only with vertically displayed line numbers but also with
> `count-words-region' (and hence with `count-lines').  What do others
> think?

Hmm... I don't understand why you needed to change the format spec to
%l, and also why the change in mode_line_update_needed.  Isn't it
enough to just produce "EOB" instead of a number?

>  static bool
>  mode_line_update_needed (struct window *w)
>  {
> -  return (w->column_number_displayed != -1
> -	  && !(PT == w->last_point && !window_outdated (w))
> -	  && (w->column_number_displayed != current_column ()));
> +  return ((w->column_number_displayed != -1
> +	   && !(PT == w->last_point && !window_outdated (w))
> +	   && (w->column_number_displayed != current_column ()))
> +	  || (line_number_displayed
> +	      && ((ZV == w->last_point && PT != ZV)
> +		  || (ZV != w->last_point && PT == ZV))));

The last 2 lines can be written more succinctly as

              && ((ZV == w->last_point) != (PT == ZV))

Re: line-number-mode at EOB

[Stephen Berman]

On Tue, 18 Jul 2017 17:55:41 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: emacs-devel@gnu.org
>> Date: Tue, 18 Jul 2017 00:20:10 +0200
>> 
>> > By that reasoning, line-number-mode (the %l construct) should be changed
>> > so as not to display a number when point is at EOB.  Perhaps it should
>> > display "EOB" or "END" instead.
>> 
>> I attempted to implement this change in the mode line display (see
>> attached patch) and the result, while admittedly only "minor aesthetic
>> sugar", seems to me not too bad: it makes line-number-mode consistent
>> not only with vertically displayed line numbers but also with
>> `count-words-region' (and hence with `count-lines').  What do others
>> think?
>
> Hmm... I don't understand why you needed to change the format spec to
> %l, and also why the change in mode_line_update_needed.  Isn't it
> enough to just produce "EOB" instead of a number?

If just mode-line-position in bindings.el is changed, that fails to
update the mode line frequently enough: if you go to point-max in
*scratch*, so the mode line displays "EOB", then continually typing C-b
or C-p doesn't change the "EOB".  Conversely, if just decode_mode_spec
is changed to output "EOB" at point-max, the current code in
mode-line-position will make the mode line display "LEOB" when
column-number-mode is disabled.  Finally, even with both of the other
changes, without the change in mode_line_update_needed, if the character
immediately before EOB is not a newline (and column-number-mode is not
enabled), then if point is at EOB, continually typing C-b will keep
displaying "EOB" until the line number changes, and if point in on the
last line but before EOB, typing C-f to move to EOB will not change the
display to "EOB".

>>  static bool
>>  mode_line_update_needed (struct window *w)
>>  {
>> -  return (w->column_number_displayed != -1
>> -	  && !(PT == w->last_point && !window_outdated (w))
>> -	  && (w->column_number_displayed != current_column ()));
>> +  return ((w->column_number_displayed != -1
>> +	   && !(PT == w->last_point && !window_outdated (w))
>> +	   && (w->column_number_displayed != current_column ()))
>> +	  || (line_number_displayed
>> +	      && ((ZV == w->last_point && PT != ZV)
>> +		  || (ZV != w->last_point && PT == ZV))));
>
> The last 2 lines can be written more succinctly as
>
>               && ((ZV == w->last_point) != (PT == ZV))

Thanks!  (I felt sure there was a shorter equivalent expression, but it
was late when I posted and I couldn't get my head around it.)

Steve Berman

Re: line-number-mode at EOB

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: emacs-devel@gnu.org
> Date: Tue, 18 Jul 2017 18:33:08 +0200
> 
> > Hmm... I don't understand why you needed to change the format spec to
> > %l, and also why the change in mode_line_update_needed.  Isn't it
> > enough to just produce "EOB" instead of a number?
> 
> If just mode-line-position in bindings.el is changed, that fails to
> update the mode line frequently enough: if you go to point-max in
> *scratch*, so the mode line displays "EOB", then continually typing C-b
> or C-p doesn't change the "EOB".  Conversely, if just decode_mode_spec
> is changed to output "EOB" at point-max, the current code in
> mode-line-position will make the mode line display "LEOB" when
> column-number-mode is disabled.  Finally, even with both of the other
> changes, without the change in mode_line_update_needed, if the character
> immediately before EOB is not a newline (and column-number-mode is not
> enabled), then if point is at EOB, continually typing C-b will keep
> displaying "EOB" until the line number changes, and if point in on the
> last line but before EOB, typing C-f to move to EOB will not change the
> display to "EOB".

Right, thanks for the explanations.

In any case, I don't think that what-line should be changed, because
it's used elsewhere, and such a change is backward-incompatible.

Re: line-number-mode at EOB

[Stephen Berman]

On Tue, 18 Jul 2017 22:03:47 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

> In any case, I don't think that what-line should be changed, because
> it's used elsewhere, and such a change is backward-incompatible.

According to rgrep, what-line occurs in these Emacs Lisp libraries:
vi.el, tpu-edt.el (both in obsolete/), f90.el, view.el, and edt.el.  In
all but one case, it's used just as a command to return the line number
at point, so for these it would be no problem if it returned "EOB" at
EOB.  The exception is f90.el, which uses it noninteractively:

                  (message "Matches %s: %s"
                           (what-line)
                           (buffer-substring
                            (line-beginning-position)
                            (line-end-position)))

I think this could only be problematic if EOB is not preceded by a
newline: then it would indeed be necessary to change the caller to
ensure that point isn't at EOB.  Alternatively, what-line could be
changed so that in noninteractive uses it always returns a line number,
even at EOB.

But anyway, it seems like the idea of not displaying a line number in
the mode line at EOB is at best too controversial to accept outright,
since there are incompatible intuitions about whether EOB is a line
(when preceded by a newline).  Given that, if it were to be included in
Emacs at all, then it should be conditioned by a user option.

Steve Berman

Re: Native display of line numbers, improved

[martin rudalics]

 > All the bugs reported till now are fixed, with the sole exception of
 > truncated-lines display.  The latter behaves better now (in
 > particular, the funny problem reported by Martin, whereby you couldn't
 > get to the line beginning, is gone),

Confirmed.  The speed is quite remarkable, BTW.

 > Comments and bug reports are welcome.  Apart of fixing bugs and
 > perhaps implementing the visual line counting, the only changes I plan
 > to commit before landing this on master is proper documentation in the
 > 2 manuals.  Otherwise, the feature is complete from my POV, so here's
 > your chance to give it a ride before it lands.

We could think about a slot in the window structure which would control
line number display for a particular window (including the tooltip and
minibuffer windows).  We'd need three values: Something like 'always'
for displaying them unconditionally, nil for respecting the window
buffer's local value and 'never' for never displaying line numbers in
that window.

martin

Re: Native display of line numbers, improved

[Eli Zaretskii]

> Date: Sun, 25 Jun 2017 11:59:30 +0200
> From: martin rudalics <rudalics@gmx.at>
> 
>  > All the bugs reported till now are fixed, with the sole exception of
>  > truncated-lines display.  The latter behaves better now (in
>  > particular, the funny problem reported by Martin, whereby you couldn't
>  > get to the line beginning, is gone),
> 
> Confirmed.  The speed is quite remarkable, BTW.

Thanks.

> We could think about a slot in the window structure which would control
> line number display for a particular window (including the tooltip and
> minibuffer windows).  We'd need three values: Something like 'always'
> for displaying them unconditionally, nil for respecting the window
> buffer's local value and 'never' for never displaying line numbers in
> that window.

Is there a use case for displaying line numbers in a window rather
than in all windows displaying a specific buffer?

The code is already involved enough, and every additional sub-feature
makes it a bit slower and less clear.  So if there are no valid use
cases for this, I'd like to wait until they come up, before coding
this.

Re: Native display of line numbers, improved

[martin rudalics]

 > Is there a use case for displaying line numbers in a window rather
 > than in all windows displaying a specific buffer?

No.  But I don't use line numbers so I can't tell.  I came to think
about it because you started to care specially about the minibuffer and
tip frames and I thought that a solution where adding such special cases
in a more genral way might be useful---just like we do with scroll bars,
margins or fringes which all exist on a per window basis.

 > The code is already involved enough, and every additional sub-feature
 > makes it a bit slower and less clear.  So if there are no valid use
 > cases for this, I'd like to wait until they come up, before coding
 > this.

Sure.  Eventually, it's up to the design of the user interface.

martin

Re: Native display of line numbers, improved

[Alex]

Eli Zaretskii <eliz@gnu.org> writes:

Firstly, thanks for working on this.

If I may, I have a couple of feature requests:

1. An option to never dynamically shrink 'display-line-number-width'
   while still dynamically growing. I dislike having column 0 constantly
   changing, so an option to only grow the width dynamically like in
   (n)linum would be very appreciated.

2. Building off of the above, it would be nice if there was an option to
   calculate the minimum line number width of a buffer when visiting it,
   like in linum.

The 2nd one I believe I could accomplish with some Lisp code, but I was
thinking that it might be more efficient/convenient if this could be
implemented in the core.

Re: Native display of line numbers, improved

[Eli Zaretskii]

> From: Alex <agrambot@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Sun, 25 Jun 2017 14:30:11 -0600
> 
> 1. An option to never dynamically shrink 'display-line-number-width'
>    while still dynamically growing. I dislike having column 0 constantly
>    changing, so an option to only grow the width dynamically like in
>    (n)linum would be very appreciated.

How is growing different from shrinking?  Just wondering.

> 2. Building off of the above, it would be nice if there was an option to
>    calculate the minimum line number width of a buffer when visiting it,
>    like in linum.

What is the definition of "the minimum line number width of a buffer"?

Re: Native display of line numbers, improved

[Alex]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Alex <agrambot@gmail.com>
>> Cc: emacs-devel@gnu.org
>> Date: Sun, 25 Jun 2017 14:30:11 -0600
>> 
>> 1. An option to never dynamically shrink 'display-line-number-width'
>>    while still dynamically growing. I dislike having column 0 constantly
>>    changing, so an option to only grow the width dynamically like in
>>    (n)linum would be very appreciated.
>
> How is growing different from shrinking?  Just wondering.

Growing is necessary in the case where the width of the new line(s)
exceeds the current 'display-line-number-width'. Of course that can
be worked around by setting 'display-line-number-width' to a
sufficiently large number, but I would like it to be no larger than what
it needs to be for the current text in the buffer.

Shrinking on the other hand is never necessary.

>> 2. Building off of the above, it would be nice if there was an option to
>>    calculate the minimum line number width of a buffer when visiting it,
>>    like in linum.
>
> What is the definition of "the minimum line number width of a buffer"?

Sorry for being vague. What I meant was "the number of digits to display
the last line in the buffer".

For example, if the file has 10000 lines, then when visiting it
'display-line-number-width' should be immediately set to 5.

Re: Native display of line numbers, improved

[Alex]

Alex <agrambot@gmail.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:

>>> 2. Building off of the above, it would be nice if there was an option to
>>>    calculate the minimum line number width of a buffer when visiting it,
>>>    like in linum.
>>
>> What is the definition of "the minimum line number width of a buffer"?
>
> Sorry for being vague. What I meant was "the number of digits to display
> the last line in the buffer".

Err, sorry again. I meant to write "the number of digits needed to
represent the last line in the buffer's line number".

Re: Native display of line numbers, improved

[Eli Zaretskii]

> From: Alex <agrambot@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Sun, 25 Jun 2017 21:50:15 -0600
> 
> Err, sorry again. I meant to write "the number of digits needed to
> represent the last line in the buffer's line number".

Right.  That would be something like

  (truncate (1+ (log (max 1 (count-lines (point-min) (point-max))) 10)))

Re: Native display of line numbers, improved

[Alex]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Alex <agrambot@gmail.com>
>> Cc: emacs-devel@gnu.org
>> Date: Sun, 25 Jun 2017 21:50:15 -0600
>> 
>> Err, sorry again. I meant to write "the number of digits needed to
>> represent the last line in the buffer's line number".
>
> Right.  That would be something like
>
>   (truncate (1+ (log (max 1 (count-lines (point-min) (point-max))) 10)))

Thanks. I was just thinking that the display engine could somehow do it
noticeably faster, but evaluating that in a large file (xdisp.c) is only
a few milliseconds on my machine, so that's probably fast enough.

Is there going to be a minor mode in the merged version? It would be
nice to have a display-line-numbers-mode-hook to attach the above to.

Re: Native display of line numbers, improved

[Eli Zaretskii]

> From: Alex <agrambot@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Mon, 26 Jun 2017 13:41:19 -0600
> 
> Is there going to be a minor mode in the merged version? It would be
> nice to have a display-line-numbers-mode-hook to attach the above to.

I have nothing against a minor mode, but I think it would be wrong for
me to code it.  It should be done by those who really use the line
numbers, and thus have experience and understanding of the interactive
and UI aspects of it.

IOW, feel free to submit the patches for that once the stuff lands on
master.

Native line numbers column disappears at times

[Kaushal Modi]

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

Hi Eli,

I have been testing out the line numbers branch for past few days. I see a
tremendous improvement over the first cut (and thank you for adding the
current line number highlight feature).

I have just 1 remark:

The line numbers column disappears at times. I have seen that to happen
only when the emacs *frame* is not in focus. As soon as I click on that
window, the line numbers re-appear. I don't yet have a recipe to
consistently recreate this.

Thanks.
-- 

Kaushal Modi

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

Re: Native line numbers column disappears at times

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Thu, 29 Jun 2017 20:25:54 +0000
> 
> The line numbers column disappears at times. I have seen that to happen only when the emacs *frame* is
> not in focus. As soon as I click on that window, the line numbers re-appear. I don't yet have a recipe to
> consistently recreate this.

Thanks for letting me know.  I do need a recipe to debug and fix this.

Re: Native line numbers column disappears at times

[Kaushal Modi]

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

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

> > From: Kaushal Modi <kaushal.modi@gmail.com>
> > Date: Thu, 29 Jun 2017 20:25:54 +0000
> >
> > The line numbers column disappears at times. I have seen that to happen
> only when the emacs *frame* is
> > not in focus. As soon as I click on that window, the line numbers
> re-appear. I don't yet have a recipe to
> > consistently recreate this.
>
> Thanks for letting me know.  I do need a recipe to debug and fix this.
>

I still see this issue even after building emacs with this feature merged
in master.

I'm not familiar with the C code. Can you please provide a patch with debug
info at the right points that can help debug this? i.e. what's causing the
line numbers to get hidden.
-- 

Kaushal Modi

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

Re: Native line numbers column disappears at times

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Mon, 10 Jul 2017 18:53:40 +0000
> Cc: emacs-devel@gnu.org
> 
> I'm not familiar with the C code. Can you please provide a patch with debug info at the right points that can
> help debug this? i.e. what's causing the line numbers to get hidden.

It's impossible to provide debugging code without understanding at
least some of the problem.  So please tell more about what you see:
what are you doing when it happens, which major and minor modes are
turned on, do all the numbers disappear or just some, what makes them
re-appear again, etc.

Thanks.

P.S. This discussion should probably become a formal bug report, so
please submit one, and let's continue there.

Re: Native line numbers column disappears at times

[Kaushal Modi]

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

On Mon, Jul 10, 2017 at 3:31 PM Eli Zaretskii <eliz@gnu.org> wrote:

>
> P.S. This discussion should probably become a formal bug report, so
> please submit one, and let's continue there.
>

Done:  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27647
-- 

Kaushal Modi

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

Re: Native display of line numbers, improved

[Eli Zaretskii]

> From: Alex <agrambot@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Sun, 25 Jun 2017 21:43:37 -0600
> 
> >> 1. An option to never dynamically shrink 'display-line-number-width'
> >>    while still dynamically growing. I dislike having column 0 constantly
> >>    changing, so an option to only grow the width dynamically like in
> >>    (n)linum would be very appreciated.
> >
> > How is growing different from shrinking?  Just wondering.
> 
> Growing is necessary in the case where the width of the new line(s)
> exceeds the current 'display-line-number-width'. Of course that can
> be worked around by setting 'display-line-number-width' to a
> sufficiently large number, but I would like it to be no larger than what
> it needs to be for the current text in the buffer.

You could do that by counting lines in the buffer in some suitable
hook, and then setting the value of 'display-line-number-width'
accordingly, right?

My point is that doing what you want requires counting lines in the
entire buffer, something that could take a considerable time.  So
doing that in the display code when people who'd like that could set
that up for them using the existing facilities sounds uneconomical.

Re: Native display of line numbers, improved

[Stefan Monnier]

Hi Eli,

I don't understand your comment: Alex is referring here to the approach
used in nlinum, which I chose specifically to avoid having to scan the
whole buffer.

Basically, start with a small value of display-line-number-width, and if
during display we find that this value is too small to fit the largest
displayed line-number, we increase it.  So when you open a very large
buffer (but where only the first 60 lines are displayed), only 2 columns
will be used for line-numbers since "it's been enough so far"; if you
move to line 2000 and back, we'll now be using 4 columns (even though
2 would be sufficient).  This means that column 0 does sometimes change,
but fairly rarely (only when you move to a line number with more digits
than what you've visited so far).


        Stefan


>> >> 1. An option to never dynamically shrink 'display-line-number-width'
>> >>    while still dynamically growing. I dislike having column 0 constantly
>> >>    changing, so an option to only grow the width dynamically like in
>> >>    (n)linum would be very appreciated.
>> >
>> > How is growing different from shrinking?  Just wondering.
>> 
>> Growing is necessary in the case where the width of the new line(s)
>> exceeds the current 'display-line-number-width'. Of course that can
>> be worked around by setting 'display-line-number-width' to a
>> sufficiently large number, but I would like it to be no larger than what
>> it needs to be for the current text in the buffer.

> You could do that by counting lines in the buffer in some suitable
> hook, and then setting the value of 'display-line-number-width'
> accordingly, right?

> My point is that doing what you want requires counting lines in the
> entire buffer, something that could take a considerable time.  So
> doing that in the display code when people who'd like that could set
> that up for them using the existing facilities sounds uneconomical.

Re: Native display of line numbers, improved

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 26 Jun 2017 11:28:23 -0400
> 
> I don't understand your comment: Alex is referring here to the approach
> used in nlinum, which I chose specifically to avoid having to scan the
> whole buffer.

I alluded to this:

> that can
> be worked around by setting 'display-line-number-width' to a
> sufficiently large number, but I would like it to be no larger than what
> it needs to be for the current text in the buffer.

I provided 'display-line-number-width' to cater to the desire of not
shrinking the width too much, and it seemed to me that if someone's
ideal is not to change the width at all, as Alex said up-thread,
counting the lines at the beginning will do that for him.

> Basically, start with a small value of display-line-number-width, and if
> during display we find that this value is too small to fit the largest
> displayed line-number, we increase it.

I wanted to avoid using a buffer-local variable settable by the
display engine.  (I cannot easily use display-line-number-width,
because that's a user-settable option; I need another variable.)

Re: Native display of line numbers, improved

[Stefan Monnier]

>> Basically, start with a small value of display-line-number-width, and if
>> during display we find that this value is too small to fit the largest
>> displayed line-number, we increase it.
> I wanted to avoid using a buffer-local variable settable by the
> display engine.  (I cannot easily use display-line-number-width,
> because that's a user-settable option; I need another variable.)

Oh, I didn't mean to use that variable.  I was just explaining that Alex
request to "grow-only" seems to work fairly well to provide "mostly
constant width" without having to scan the whole buffer upfront.
How to provide "grow-only" (i.e. where to store the previous-width info)
is not something I've thought about, but maybe it can be kept as
a window-local information, reset whenever we set-window-buffer.


        Stefan

Re: Native display of line numbers, improved

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: emacs-devel@gnu.org
> Date: Mon, 26 Jun 2017 12:12:34 -0400
> 
> Oh, I didn't mean to use that variable.  I was just explaining that Alex
> request to "grow-only" seems to work fairly well to provide "mostly
> constant width" without having to scan the whole buffer upfront.

Yes, the idea is fairly clear ;-)

> How to provide "grow-only" (i.e. where to store the previous-width info)
> is not something I've thought about, but maybe it can be kept as
> a window-local information, reset whenever we set-window-buffer.

A variety of ways exist, but each one comes with some, albeit minor,
disadvantage and added complexity.  So I'd like first to see whether
this is needed, on top of what's already there.

Basically, I'd like to keep the feature as simple and lightweight as
possible, leaving the 20% percent to local customizations, rather than
forcing everyone to bear the price.

Re: Native display of line numbers, improved

[Alex]

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

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Date: Mon, 26 Jun 2017 11:28:23 -0400
>> 
>> I don't understand your comment: Alex is referring here to the approach
>> used in nlinum, which I chose specifically to avoid having to scan the
>> whole buffer.
>
> I alluded to this:
>
>> that can
>> be worked around by setting 'display-line-number-width' to a
>> sufficiently large number, but I would like it to be no larger than what
>> it needs to be for the current text in the buffer.
>
> I provided 'display-line-number-width' to cater to the desire of not
> shrinking the width too much, and it seemed to me that if someone's
> ideal is not to change the width at all, as Alex said up-thread,
> counting the lines at the beginning will do that for him.

Counting at the beginning helps a lot, but it doesn't help for when the
buffer grows over an editing session.

>> Basically, start with a small value of display-line-number-width, and if
>> during display we find that this value is too small to fit the largest
>> displayed line-number, we increase it.
>
> I wanted to avoid using a buffer-local variable settable by the
> display engine.  (I cannot easily use display-line-number-width,
> because that's a user-settable option; I need another variable.)

What's the difference between the display engine setting a buffer-local
variable and Lisp libraries doing so?

I've included a diff that accomplishes what I want. Is there something
fundamentally wrong it?

PS: There's a bug with tab stops when display-line-number-width is a
small positive number. Look at around L20814 in xdisp.c with a
display-line-number-width being nil, 1, 2, and 3.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: line-numbers-grow-only.diff --]
[-- Type: text/x-diff, Size: 1755 bytes --]

diff --git a/src/xdisp.c b/src/xdisp.c
index aa75fcaf77..442b09b10b 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -20810,8 +20810,21 @@ maybe_produce_line_number (struct it *it)
   /* Compute the required width if needed.  */
   if (!it->lnum_width)
     {
-      if (NATNUMP (Vdisplay_line_number_width))
-	it->lnum_width = XFASTINT (Vdisplay_line_number_width);
+      if (display_line_numbers_grow_only && NATNUMP (Vdisplay_line_number_width))
+	{
+	  int min_lnum = XFASTINT (Vdisplay_line_number_width);
+	  ptrdiff_t max_lnum;
+
+	  max_lnum = this_line + it->w->desired_matrix->nrows - 1 - it->vpos;
+	  min_lnum = max (log10 (max_lnum) + 1, min_lnum);
+
+	  it->lnum_width = min_lnum;
+	  Vdisplay_line_number_width = make_number (min_lnum);
+	}
+      else if (NATNUMP (Vdisplay_line_number_width))
+	{
+	  it->lnum_width = XFASTINT (Vdisplay_line_number_width);
+	}
       else
 	{
 	  /* Max line number to be displayed cannot be more than
@@ -32495,6 +32508,14 @@ even if the actual number needs less space.
 The default value of nil means compute the space dynamically.
 Any other value is treated as nil.  */);
   Vdisplay_line_number_width = Qnil;
+  DEFSYM (Qdisplay_line_number_width, "display-line-number-width");
+  Fmake_variable_buffer_local (Qdisplay_line_number_width);
+
+  DEFVAR_BOOL ("display-line-numbers-grow-only", display_line_numbers_grow_only,
+	       doc: /* Non-nil means only dynamically grow the
+display, and never shrink. This variable is only taken into account
+when `display-line-number-width' is a positive number.*/);
+  display_line_numbers_grow_only = false;
 
   DEFVAR_BOOL ("inhibit-eval-during-redisplay", inhibit_eval_during_redisplay,
     doc: /* Non-nil means don't eval Lisp during redisplay.  */);