bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#28533: 26.0.60; Native line numbers move with show-paren-mode enable


From: Eli Zaretskii
Subject: bug#28533: 26.0.60; Native line numbers move with show-paren-mode enabled
Date: Thu, 21 Sep 2017 12:11:42 +0300

> From: Romanos Skiadas <address@hidden>
> Date: Wed, 20 Sep 2017 21:14:02 +0100
> 
> - Start emacs
> ./src/emacs -Q --eval "(add-hook 'text-mode-hook (lambda () 
> (display-line-numbers-mode)))" --eval "(show-paren-mode 1)" /tmp/test.org
> 
> - Write about 100 lines or so and fold the org header. Something like
> 1 * Foo...[100 lines folded here]
> 
> - Enter a pair of parens under the folded header:
> 1 * Foo...
> 123 ()
> 
> - Move the point from left to right with C-f and the line number moves:
> 1 * Foo...
> 123 |()
> 123 (|)
> 123 ()|
> 
> As far as I could tell, without the folded lines or show-paren-mode this
> does not happen. It can also be replicated in modes other than org by
> using set-selective-display.

In modes that hide many lines from display, you should customize
display-line-numbers-width-start to a non-nil value, or manually set
display-line-numbers-width to a value large enough to accommodate the
last physical line of the file (e.g., in file-local variables).
Otherwise the default calculation of the width required for line
numbers will come up with a value that is lower than necessary, and
you will frequently see that some lines displayed in the window are
shifted to the right due to this miscalculation.

This issue is part of that more general problem.  What happens here is
that the original calculation of the width of line-number display is
incorrect, and the additional redisplay cycle caused by moving the
show-parent overlay "corrects" it.

Note that this effect is only seen on the last line of the file, and
AFAICS only as long as you don't save the buffer.

Based on the fact that having line numbers in buffers under
selective-display requires customization of the provided options,
which then makes this problem go away, I don't think any fix is
required for this use case.  If you agree, I will close this bug.

Thanks.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]