Show infobox with register contents

[sudormrfbin]

Fixes #965.

[archseer]

Why the need for take() here?

[archseer]

Ah I see, it sits on the editor now

[archseer]

It could be an extra field on the context? That way UI is fully stored on the ui::Editor

[EpocSquadron]

So there is an issue that occurs if one of the registers contains more than one line that doesn't get truncated away by the character limit. In that case, the infobox will not be high enough to fit all of the info text, as the height is set to the number of strings in the body vec passed to it. There's two ways around this -- we can alter the calculation of the height to include newlines in each body item, or we can truncate the register contents at whichever comes first of the character limit or first instance of a newline. I would argue for the former, as there could conceivably be other cases where the description of an item should wrap in the future, and the info box should be robust against that.

[EpocSquadron]

In current state, this works pretty well. One corner case I mentioned in the original issue was that some registers can contain multiple selections. I don't know how much effort it would be to add some description of the number of selections to the infobox somewhere. In my head I see a table setup where there's a third aligned column with "24 sels" and the like for registers that have them. That column would not appear if none of the registers had more than one sel. If we want that to be a separate issue so we can merge this sooner, that's cool too.

[EpocSquadron]

Building on both my previous comments, it might be nice to show an ellipsis with the number of lines occupied by a register when there are more than 3 total lines. This could be combined with the selection number hint in something like this:

"     <style>
        .someClass {
   … (16 more lines)
: theme everforest_dark
/ style
b [5 sels]
      :v-if="language == 'en-US'"
      :checked="checked"
   … (2 more lines in first sel)

It's a bit ugly, so it might be worth some more noodling over format. I can also see it being a little finicky. For example, if the second line of a register's contents cause the character limit to take effect, we still need to display the number of additional lines below it, which might be missed if we specifically look for more than 3 lines.. that kind of thing.

Maybe we could colorize the hints and buffer identifiers to make things a little clearer?

[Omnikar]

On the issue of registers containing multiple selections, perhaps the infobox could just show the contents of the first selection, and then we can have a command like :reg which can be used to pull up a full view of all the selections of a given register?

[EpocSquadron]

On the issue of registers containing multiple selections, perhaps the infobox could just show the contents of the first selection, and then we can have a command like :reg which can be used to pull up a full view of all the selections of a given register?

I think down the road it would be cool to have something like that that uses the picker interface to see the history of items in that register (like yank-ring), which would both give a better view of the contents as well. For this particular pull request though, I'm looking for a quick reminder on-the-fly of what registers are available and what's in them presently. I think because of that intended purpose, it makes sense sense to also hint the number of selections, but I wonder if we save that at this point for a separate pull request and stick to just addressing the bug with multi-line contents. Once the basic functionality is out in the wild, more people might pop up with ideas on how to evolve the functionality.

[sudormrfbin]

Rebased and pushed. It's usable enough in the current form, and I think we can address the suggested improvements separately so that this can get merged sooner.

[EpocSquadron]

So there is an issue that occurs if one of the registers contains more than one line that doesn't get truncated away by the character limit. In that case, the infobox will not be high enough to fit all of the info text, as the height is set to the number of strings in the body vec passed to it. There's two ways around this -- we can alter the calculation of the height to include newlines in each body item, or we can truncate the register contents at whichever comes first of the character limit or first instance of a newline. I would argue for the former, as there could conceivably be other cases where the description of an item should wrap in the future, and the info box should be robust against that.

I think this one never got resolved. I can't recall if it caused a panic, but probably should double check before we merge.

[sudormrfbin]

Thanks for reminding @EpocSquadron :) Fixed in dbdb645.

[archseer]

Great work! 🎉