WIP: Utility Gutter

[dannasessha]

DRAFT. Fixes #1188.

Working toward an additional, configurable gutter, and to make gutters more configurable generally.

The new utility gutter should be able to handle arbitrary text, likely corresponding to the opened document. For example, the gutter could display short commit hashes by line provided by git annotate.

[sudormrfbin]

We don't have plugins yet, so configuring the utility gutter to show arbitrary text would have to happen through the TOML config, and I'm not sure if we should allow that. I imagine it would need to execute a shell command, clip the output size, conditionally run it, etc. It could grow into a DSL within the toml config and that's something we want to avoid (i.e. strapping on programming features to a config language).

[archseer]

Yeah, I was expecting the gutter fns themselves be flexible enough that plugins can use them to define new gutters -- rather than one generic utility gutter.

[archseer]

The config would just be an array of which gutters to use (and the widths?), it would replace the hard-coded gutters in view.rs

[dannasessha]

Thank you both for looking over this code.

We don't have plugins yet, so configuring the utility gutter to show arbitrary text would have to happen through the TOML config, and I'm not sure if we should allow that. I imagine it would need to execute a shell command, clip the output size, conditionally run it, etc. It could grow into a DSL within the toml config and that's something we want to avoid (i.e. strapping on programming features to a config language).

I wouldn't want to put scripting into the TOML.

Yeah, I was expecting the gutter fns themselves be flexible enough that plugins can use them to define new gutters -- rather than one generic utility gutter.

Okay. I really don't know what type of interface plugins are going to have, but I do think I understand what you're saying overall.

I think having multiple possible gutters specified by plugins or other means like TOML and making it extensible sounds great! Do you mean by abstracting GUTTERS to iterate over a collection of function calls?

I see #769 but I didn't study it yet.

I was hoping (at least ultimately) to have the ability to do things like pass arbitrary text (maybe plugin or real-time, or pre-generated) to the gutters (which I would imagine would often correspond to line numbers) but I also didn't know exactly how I was going to approach it. Right now the out which prints to the user's gutter is defined in gutters.rs, matching the previously exisiting gutters, maybe we could incorporate reading in another buffer or file, or some kind of similar function within that module..?

Is there a plugin interface that I should look at? Or even a plan for one I could use to demo something?

The config would just be an array of which gutters to use (and the widths?), it would replace the hard-coded gutters in view.rs

Yes, and I have been working locally on some things more in this direction, I think. What you're suggesting might not come online immediately but I'd like to continue on this branch if it's worth people's time to consider.

[irevoire]

(and the widths?)

I would very much like to not make the width mandatory if possible.

[dannasessha]

(and the widths?)

I would very much like to not make the width mandatory if possible.

My plan is to make the current two gutters default to on (diagnostic has width 1, no reason to change it by default that I see.) Other non-line-number gutters would not be on by default, they would have to be triggered by virture of a user signal, either by a plugin or a config are my two current thoughts.

The line_number gutter width is currently hard coded to 5, with tests to go along with that setting. I would like to make this width elastic (including allowing 0 by config) - probably matching the number of lines in the file, if that is possible. I will have to test what happens when a document goes above or below a number limited by the number of digits and try to avoid confusing situations. I see that some work has been done around #769, I will investigate.

[dannasessha]

I wasn't able to definitively cut into this problem with my level of understanding of helix.

I still think having a configurable utility gutter (and flexible, configurable width gutters) is a good idea, but I was not yet able to make definitive progress. I may try to return to this issue, but I have stopped active attempts for the time being.

[dannasessha]

Pushing commits of last changes I was working with locally.

[pickfire]

@dannasessha I converted it to draft, later once you are done can convert it back.

[the-mikedavis]

Should we close this out? With #1967 merged it may be easier to restart from master. The customizable "utility" gutters may have to await the plugin system anyways, no?

[archseer]

Yep, agreed