Selecting long lines in a diff hunk in Emacs 25 highlights extra lines

[fice-t]

1. First make some changes to a file so its diff contains lines longer than the width of the Emacs window.
2. From emacs -Q load magit and enter the status buffer for the repo.
3. View the diff and go the end of the line (past the window edge).
4. C-SPC to select the line.

Notice how it's normal in Emacs 24.5 but in 25.1 the lines above and below the line are highlighted as well, pushing the selected line and the one below it down 1/2 lines respectively.

PS: I noticed how if you have consecutive lines that go past the window edge and you try to use the mouse to click and drag a region, the selection will jump right to the bottom of the lines instead of going line by line as would happen when using the keyboard.

Magit 20160902.1451, Git 2.9.3, Emacs 25.1.1, gnu/linux

[npostavs]

I can confirm.

PS: I noticed how if you have consecutive lines that go past the window edge and you try to use the mouse to click and drag a region, the selection will jump right to the bottom of the lines instead of going line by line as would happen when using the keyboard.

This part happens in 24.5 as well.

---

Both these issues are fixed using the np/overlay-rm-nl branch (which I've just rebased onto master). Though it has its own minor problems: move-end-of-line will skip to the next line, and the bottom line doesn't quite get rendered far down enough (because it's an underlining of text).

[fice-t]

PPS: I noticed that if you click once on a diff hunk in 25.1 then the line will automatically be highlighted, but in 24.5 it just positions the point like expected.

I wonder what happened in 25.1 that broke this.

[tarsius]

I am trying to wrap my head around the changes in np/overlay-rm-nl again. There's a lot of fixup commits in there and failed and reverted attempts. That's good it tells us about what we were thinking, but it would be better if we had branches for the various attempts and things were ordered logically instead of historically.

[tarsius]

I have pushed the result to a new branch overlay-rm-nl.

[tarsius]

I noticed that if you click once on a diff hunk in 25.1 then the line will automatically be highlighted, but in 24.5 it just positions the point like expected.

That has annoyed me for a while to but I did not realize it was a regression with 25.1.

I wonder what happened in 25.1 that broke this.

Some code that used to be run when the mouse is dragged is now already run on mouse-down-1, I suppose.

Anyway, I fixed it.

[tarsius]

Hm, not quite, seems a bit more complicated.

[tarsius]

In v25.1 the region highlighting happens at a different time in the command loop than it used to. It now happens after this-command is already nil again.

[tarsius]

Though it has its own minor problems: move-end-of-line will skip to the next line, and the bottom line doesn't quite get rendered far down enough (because it's an underlining of text).

I cannot reproduce these issues anymore with v25.1! If you can confirm that, then we should probably start using the new implementation at least for that Emacs version.

[tarsius]

We should squash the commits and the final commit message should explain each change. There should probably be a bullet point for each of the current commits. @npostavs could you please do that for your commits, I don't fully understand all the current commit messages.

[npostavs]

I cannot reproduce these issues anymore with v25.1!

Oh, I got mixed up as to which thing is broken where, see #2293 (comment) for the correct details. The move-end-of-line thing is only broken in v24 indeed. There is still the temporary-goal-column problem in both, to see, move to the end of a shorter line and then hit C-n to move to a longer one. Point moves to end of line instead of staying in the same column.

I do see the line rendering thing regardless, it might depend on the font. Here is a screenshot, notice the orange line crosses the |.

could you please do that for your commits, I don't fully understand all the current commit messages.

I'll try to squash things down into something more managable tomorrow.