feat: allow passing footer in input and select with builtin backend

[chrisgrieser]

For input and select (with the builtin backend), add support for adding a footer via the opts of vim.ui.input and vim.ui.select, for example:

vim.ui.input({
	prompt = "Hello World",
	footer = "foobar",
}, function(text) print(text) end)

Context

What is the problem you are trying to solve?
Increase customizability.

Test Plan

list the steps you took to test this functionality. Steps should be
reproducible by others.
I ran the code block above.

[stevearc]

I've been very hesitant to support any kind of API that departs from the built-in vim.ui methods. The reason is that it could lead to fragmentation in the ecosystem. If I add features, they won't be supported across all implementations so plugin authors, if they want to use them, will have to reason about what the UI will be if the end user is using dressing.nvim vs what it will be if they're using something else. It's not quite as bad as plugin authors needing to implement these methods themselves for all of telecope, fzf, nui, etc, but it does start to defeat the point of creating the vim.ui interface. The promise of vim.ui is that plugin authors get to use a single, standardized API that expresses their goal, and the end user gets to customize the look and feel of how that goal is accomplished.

The other issue is that if the vim.ui methods change upstream and they add more capabilities, we run the risk of colliding with the features that they add. This can cause a big tangle of problems.

The one concession that I have made to this so far is to add the ability to pass in some options to customize the telescope UI. The reason for this is that this is something that will never make it into core (they won't put in logic specific to third-party plugins) and it doesn't impact the functionality of vim.ui.select. It is functionally very similar to a plugin author doing "if telescope installed, use custom telescope picker, else use vim.ui.select," but it's more convenient because they don't have to write the entire picker, just the layout.

If we wanted to treat this like the telescope customization, we could do something like put all the options under a key that is guaranteed to not be used upstream (like dressing). That solves the collision problems, but there's one additional difference between this and telescope. The telescope customization merely enables the plugin author to configure how the information will be displayed. This API adds new information to be displayed. That means that there is now some information that will only be displayed to users sometimes, depending on what implementation of vim.ui they are using. Since you can't rely on it being shown, you can't put anything critical there. Since that information isn't critical, does it merit adding a custom API to enable it? My thought is probably not. I could possibly be convinced, but I would have to be shown some concrete real-world use cases where this provides a significant benefit.

[chrisgrieser]

Hmmm, true, you make a good point, I haven't thought far enough ahead here. I agree, the long-term compatibility with vim.ui is more relevant here than this

[chrisgrieser]

I just realized that from the plugin author side, it's actually not a problem anyway, as I discovered that you can change things like window options after window creation via nvim_win_set_config().

Just as a FYI/showcase, in tinygit, my git plugin that uses dressing for all its UI, I added a character count in the footer, since it's quite helpful to see whether your commit message has overlength.