When line annotations wrap to a new line the down arrow behavior breaks

[jncorpron]

🔢 Steps:

1. Start with a file of ~3 non-blank lines of code
2. make the second line a really long line of code
3. Commit the file to git
4. place 1 cursor in the middle of the line (Note, at this point expect to see the line annotation on the next line, though I, the issue submitter have no idea how this logic works. Sometimes I see that long lines have the annotation at the end, and the buffer is widened, sometimes the annotation is on a new line following the long line 😕)
5. ⬇️ use the down arrow key (cursor moves to the end of the line)
6. ⬇️ use the down arrow key (cursor moves to the end of the file)

The 🐛 Bug: Both steps 5 & 6 cause the cursor to move to a position in the file where it would not, if the line annotation or GitGutter are disabled. This breaks the ease-of-use of most of the ST editing commands that use the ⬆️ up & ⬇️ down keys 😭 which is pretty essential for editing quickly (particularly when the cursor mysteriously jumps to the end of the file).

Maybe relevant info:

• I have a 80 character ruler set
• The screen width I have right now in my editor is about 150 characters wide

PS: the line annotation feature is interesting 👍, but it's also not obvious that GitGutter, "plugin to see git diff in gutter", is the plugin that adds annotations to the editor buffer. Maybe you should consider making this feature another, distinct plugin?

[deathaxe]

Line annotations are phantoms with the LAYOUT_INLINE flag which are added to the very last character of a line, so they are expected to always render after a line. It works well, if word wrapping is disabled. Therefore the default setting "auto" disables line annotations if word wrapping is enabled.

With "git_gutter_show_line_annotation": true line annotations are added even if word wrapping is enabled and might cause the line annotation to be displayed at the next line as ST includes it into its word wrapping. This behavior can't be changed.

The cursor behavior is completely handled by ST core. Adding phantoms to empty lines makes the cursor behave badly as well, hence no annotations are displayed then. If you don't like the cursor's behavior you would need to file an issue at https://github.com/SublimeTextIssues/Core/issues. It can't be fixed from plugin side.

The "blame" information are gathered once and published as line annotations and can be added to the status bar. Both use jinja2 to enable the user to fully customize the output. Creating a dedicated plugin would therefore reduce the flexibility of status bar customization and require the whole infrastructure of calling git and parsing the output to be copied and maintained twice. Not worth the effort.

If the line annotations cause issues, you can disable them and try "Git Blame" package, which adds phantoms with the same info to the next line via key binding.

[jncorpron]

I'm not sure I understand all of the technical detail you replied with, but it sounds like the solution is that it's not fixable and my solution of turning line annotations off was the right one.

I'm fine with not using the feature, I just meant to let you all know that there was a bug. I'm okay with whatever resolution you'd like.

[deathaxe]

You understood correctly. The current solution is the best possible with the available core functions.

All "bugs" related with

• jumping cursors
• unclickable whitespace after line end
• line height shifts if phantoms are added with very small lines
• line annotation being wrapped to the next line
• ...

are caused by the underlying phantom API being used to render line annotation.

[deathaxe]

This issue will be fixed for ST4 via annotations API.