signcolumn: auto: re-use same column for same type

[blueyed]

With e.g. :set signcolumn=auto:2 and two different plugins displaying signs, it would be nice if signs were trying to be kept in the same columns.

E.g.

AABB line1
AA   line2
  BB line3
AA   line4
  BB line5

Currently it would look like this:

AABB line1
AA   line2
BB   line3
AA   line4
BB   line5

This makes it harder to read with e.g. using vim-gitgutter and coveragepy.vim.

There have been patches in Vim already for "group"ing of signs, which could be used here, but often plugins will either re-use the same ID, or at least the same text/hl (although those might be several).

[da-x]

Original author of auto:X here. I'd also like to see this. What we have is that signs are sorted per line by ID of the signs in the line. As long as the ID ranges per plugin are not overlapping, we are okay, but it wouldn't be enough - we do need some sort of grouping that is calculated per buffer before redraw, and lazily, if signs have changed since the last redraw.

I see two main ways to tackle the grouping issue:

1) We can also introduce a new option that would allow the user to assign order and grouping using the sign names. For example: set signcolorder=GitGutter;NoCoverage,NoBranchCoverage. Groups are separated by ;, each sign name in a group separated by ,. Plugin authors can add code to append to signcolorder.

2) Alternatively, a global Git registry to allow the various plugin writers to group their plugin signs by ID ranges. For each ID range a fixed position in the sign column can be calculated in redraw, and we would need an option to define the groups. For example, set signcolranges=4000-10000,0-1000.

At any case, I don't see how we can do this without adding options or extending APIs.

[bfredl]

Point 1 could also allow to use sign group names in the new API. This would be more robust and convenient than attempting to assign unique ID ranges to plugins, though it is only supported on recent Vim 8.1 and Nvim.

[blueyed]

Wouldn't the sign group (via sign_place) help here already - as a default at least?

[da-x]

Depends. Having a texthl= for sign define is optional, no?

[famiu]

Sorry for bumping this but I really want this feature to be implemented, currently my sign columns look very messy and unappealing, this can probably solve that issue

[talk2drys]

to put visual here is how it look

also not sure if there is a way to align the signs in the gutter to the right closer to the number line. at least that would be a workaround for the git signs

[airblade]

not sure if there is a way to align the signs in the gutter to the right closer to the number line

It's not possible to declare that signs should be right-aligned. However each sign comprises 2 characters so you can effectively make the 1-visible-character signs right-aligned by defining them with the space on the left instead of the right. For example:

let g:gitgutter_sign_added = ' +'

[pjcj]

This request doesn't seem to have much support but it's something I'd love to see. If anyone does get around to implementing it I'd also like to not only have the ability to have a signcolumn dedicated to one or more groups but also for it to show only if there are signs to display in that column.

[clason]

Grouping should be based on group (for legacy signs) or namespace (for extmark signs) and ordered by priority in both cases, and this should be done by default; no need for any additional interface.

[lewis6991]

From an implementation POV, grouping by group/namespace and priority would be much more difficult than just using the priority as the extra dimension adds many more scenarios.

Trying to think of a way we can implement this without excessive scanning.

[clason]

Yes, that sounds like a reasonable compromise, especially for a first implementation.