diff-hl is not updated in Terminal sessions on scroll/jump.

[nikhgupta]

When working with terminal sessions, diff-hl will not update the git gutter signs when the buffer is scrolled or jumped from one point to another.

Moreover, forcing the hl to update itself by saving the buffer does not work when there are no changes to be saved.

Here is an outdated hl view:

[tuhdo]

cc @dgutov

[dgutov]

Why would the signs need to be updated on scrolling?

[nikhgupta]

@dgutov signs actually disappear on scrolling. That is, signs are shown for the portion of the buffer that is in the view, but if you scroll down a bit in the buffer, no signs are shown for the new lines. In the screenshot, signs were updated while line 77 was the last line in view, and hence after scrolling a bit downwards, the signs for lines 90-95 (for example) are missing.

[dgutov]

signs actually disappear on scrolling

That must be because of some other more you have enabled. Maybe it's Linum. As we can see on the screenshot, some line numbers are wrong as well.

The solution is to either stop using Linum, or to display diff-hl indicators in the fringe.

[syl20bnr]

@dgutov Seems that global-hl-line-mode is one thing that draw over diff-hl, linum is another thing.
Do you think it is possible to correctly shift the numbers of linum one character to the right when diff-hl is enabled ?

[dgutov]

global-hl-line-mode

What about it?

Do you think it is possible to correctly shift the numbers of linum one character to the right when diff-hl is enabled ?

I don't even understand what you're asking. Look! The beginning of the screenshot has 9 lines number 6 and 3 lines number 7. That is because linum-mode is using the margin, and you've made diff-hl use the margin too (via diff-hl-margin-mode); the uses of margin don't compose.

Either move it to the right margin, or back to the fringe.

[tuhdo]

@dgutov it's a problem in terminal mode. There's no fringe in it. Here is how to reproduce it:

• Enable diff-hl-margin-mode.
• Edit a file under version control then save it.
• See diff-hl markers.
• C-v next page and M-v to go back.
• The markers disappears.

This is with linum-mode enabled. Seems like after refreshing, the line number delete the markers.

The problem with right margin is that if you have to buffer, only the right most buffer can use the margin.

[dgutov]

Seems like after refreshing, the line number delete the markers.

Indeed. Any suggestions? Frantically redrawing indicators after scrolling just because someone might have overwritten them is not a good idea (it introduces a race condition, for one).

[dgutov]

Oh. Instead of linum, try nlinum from GNU ELPA. It doesn't have this exact problem.

[tuhdo]

You're right. Maybe we could try. Also, nlinum gives much higher performance compared with linum. @syl20bnr what do you think?

[syl20bnr]

I think we should try it, I wonder if relative line numbers will work with
it though.

There is still the issue of the highlight of the current line which erases
the marker too.

Honestly the margin of diff-hl in its current state is not really usable
:-(

In the terminal redrawing cost is less than in the GUI (well on a local
host) so we could allow us to make some smart redraws.

Le vendredi 12 juin 2015, Tu Do notifications@github.com a écrit :

You're right. Maybe we could try. Also, nlinum gives much higher
performance compared with linum. @syl20bnr https://github.com/syl20bnr
what do you think?

—
Reply to this email directly or view it on GitHub
#1959 (comment)
.

-syl20bnr-

[dgutov]

I wonder if relative line numbers will work with it though.

They probably won't. If you're not satisfied with the current state of affairs WRT margins, you should file a feature request with M-x report-emacs-bug. Even if that won't help the current users.

There is still the issue of the highlight of the current line which erases the marker too.

I'm not aware of that, and I don't see any related open issues.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!