[mini.pick] Colorscheme picker with preview

[pkazmier]

I added a colorscheme picker to my configuration this morning and thought I'd share in case others were interested. If you preview a colorscheme, it will change your current colorscheme to the one you are previewing. If you cancel the picker, it will revert back to the colorscheme you had before you entered the picker.

Screen.Recording.2024-06-08.at.10.24.59.AM.mov

To track state of the original picker, I added the ability to have custom pre- and post-hooks for individual pickers:

-- Picker pre- and post-hooks ===============================================

-- Keys should be a picker source.name. Value is a callback function that
-- accepts same arguments as User autocommand callback.
local hooks = {
  pre_hooks = {},
  post_hooks = {},
}

vim.api.nvim_create_autocmd({ "User" }, {
  pattern = "MiniPickStart",
  group = vim.api.nvim_create_augroup("minipick-pre-hooks", { clear = true }),
  desc = "Invoke pre_hook for specific picker based on source.name.",
  callback = function(...)
    local opts = MiniPick.get_picker_opts() or {}
    local pre_hook = hooks.pre_hooks[opts.source.name] or function(...) end
    pre_hook(...)
  end,
})

vim.api.nvim_create_autocmd({ "User" }, {
  pattern = "MiniPickStop",
  group = vim.api.nvim_create_augroup("minipick-post-hooks", { clear = true }),
  desc = "Invoke post_hook for specific picker based on source.name.",
  callback = function(...)
    local opts = MiniPick.get_picker_opts() or {}
    local post_hook = hooks.post_hooks[opts.source.name] or function(...) end
    post_hook(...)
  end,
})

With that in place, here is the definition of my colorscheme picker:

-- Colorscheme picker =======================================================

local selected_colorscheme -- Currently selected or original colorscheme

hooks.pre_hooks.Colorschemes = function()
  selected_colorscheme = vim.g.colors_name
end

hooks.post_hooks.Colorschemes = function()
  vim.cmd("colorscheme " .. selected_colorscheme)
end

MiniPick.registry.colorschemes = function()
  local colorschemes = vim.fn.getcompletion("", "color")
  return MiniPick.start({
    source = {
      name = "Colorschemes",
      items = colorschemes,
      choose = function(item)
        selected_colorscheme = item
      end,
      preview = function(buf_id, item)
        vim.cmd("colorscheme " .. item)
        vim.api.nvim_buf_set_lines(buf_id, 0, -1, false, { item })
      end,
    },
  })
end

[echasnovski]

Very nice! I think there were plans of including something like this in 'mini.extra'. Probably decided that it is fairly trivial to implement and left to the user.

I'd also think about applying color scheme not only inside preview, but also after choosing.

[pkazmier]

I'd also think about applying color scheme not only inside preview, but also after choosing.

It does apply if you choose it.

I don’t explicitly run the colorscheme command in the choose function because it would revert to the original colorscheme that was saved in the pre hook upon exit. The choose function simply sets the name of the selected item and the post hook is where the colorscheme command actually runs. This is how I’m able to revert to the user’s original scheme if they cancel.

[pkazmier]

Very nice! I think there were plans of including something like this in 'mini.extra'. Probably decided that it is fairly trivial to implement and left to the user.

Like you said, it was trivial to add the colorscheme picker and I’ve had that in my config for a while now. But it was not so trivial, at least for me, to figure out how to get preview working—especially if the user cancelled the picker. So, this morning, that’s how I landed up with the ability to add pre and post hooks for any picker, which I thought was pretty cool.

[echasnovski]

I don’t explicitly run the colorscheme command in the choose function because it would revert to the original colorscheme that was saved in the pre hook upon exit. The choose function simply sets the name of the selected item and the post hook is where the colorscheme command actually runs. This is how I’m able to revert to the user’s original scheme if they cancel.

Yeah, my bad. Didn't pay close attention to the content of the hooks. Overall makes sense.

[abeldekat]

Nice! I also use this idea. I did have to set the colorscheme like so:

  local on_stop = function()
    vim.schedule(function() -- must use schedule, otherwise eyeliner stops displaying
      vim.cmd.colorscheme(selected_colorscheme)
    end)
  end

[swahpy]

it would be great if this could get integrated into mini.extra. +1

[echasnovski]

I'd ask you to at least postpone it. I am not yet entirely sure if built-in colorscheme picker is a good idea long-term (it might be at least a good use case for a custom example) and the implementation details.

The picker for autocommands is even less urgent as I mostly don't see a valid use case for it. What would you expect it to do?

[krovuxdev]

The picker for autocommands is even less urgent as I mostly don't see a valid use case for it. What would you expect it to do?

The purpose of the autocommands picker is to provide a way to see which autocommands are currently active and what they are doing. For example, running it would display something like:

CursorMoved          ▏MiniIndentscope             ▏*                         ▏Auto draw indentscope lazily
CursorMoved          ▏MiniCursorword              ▏*                         ▏Auto highlight cursorword
CursorMoved          ▏matchparen                  ▏*                         ▏call s:Highlight_Matching_Pair()
CompleteChanged      ▏IndentBlankline             ▏*                         ▏<lua function>
ColorScheme          ▏MiniStatusline              ▏*                         ▏Ensure colors
...

This would help users quickly inspect what autocommands are currently being used, which plugin registered them, and their corresponding actions. It can be useful for debugging and understanding how different plugins interact with events.

@echasnovski Would this be a valid use case for you?

[echasnovski]

For just examining it can be done with :au command (see :h autocmd-list). So, something like :au * <buffer> will show all autocommands for the current buffer, etc. Yes, it is not as interactive as in picker, but usually gets the job done.

Some of my issues with the dedicated picker for autocommands are:

• There is no suitable "choose" action. The main design of 'mini.pick' is for the picker to be used to pick something. The absence of "choose" action somehwat contradicts it.
• I really think that this is a rather niche use case. Not many people want/need to explore currently active autocommands. And for those who do want/need, exploring the :au command is even beneficial (at least in long term).

[krovuxdev]

I see your point. While :au does provide the information, a picker could improve usability by making it easier to filter and explore autocommands interactively. For example, users could quickly search by event, source, or action instead of scrolling through a long list.

Additionally, selecting an autocommand in the picker could open the file where it was defined (if available). This would make it more useful for debugging and understanding how autocommands are set up.

I understand if you think it's unnecessary, but for me, it's more convenient than running :au.

[echasnovski]

Additionally, selecting an autocommand in the picker could open the file where it was defined (if available). This would make it more useful for debugging and understanding how autocommands are set up.

Yeah, that would be useful. Unfortunately, it will only be possible for autocommands with function callback (and not Vimscript command) and not in 100% cases. And even getting to that point is not really pretty.

[echasnovski]

After several times going back and fourth, I think having relatively concise colorschemes picker in 'mini.extra' should be worth it.

@pkazmier, as an original author of this, are you interested in PR? Some notes in advance:

• No need for a general hooks approach. A single MiniPickStop autocommand with once = true that applies selected_colorscheme should be enough here (should also take care to not run :colorscheme if it not needed, i.e. target color scheme is already applied).
• It would be good to incorporate 'mini.colors' capabilities (if it is present) for picker to be able to restore initial state even if there is no vim.g.colors_name defined.
• It needs tests for both common and various tricky cases. Like:
  • Navigating up/down with enabled preview should show different previews.
  • Cancelling without choosing should restore original color scheme.
  • Choosing marked should choose first marked item (which is default in 'mini.pick', but should still be tested).

[pkazmier]

Unfortunately, I don’t have time at the moment due to a lot of travel as part of my day job. Thank you for asking me!

[echasnovski]

That's a shame. I didn't mean to do it right away, though :) A week or two is a reasonable time to wait here. But judging by your GitHub activity it might still be too soon.

[krovuxdev]

@echasnovski opinions?
I like to see the color syntax working in the preview.
It also works when exiting or pressing escape restores the original color scheme without usinghooks or MiniPickStop.

colorscheme.mp4

[krovuxdev]

If you like it, I'll open a PR in case you're interested :).

[echasnovski]

Thanks for the suggestion!

I'll wait about a week for possible @pkazmier availability and then will probably do it myself. Mostly because of the idea you gave about a more informative preview window content. I think it is better to have something like selected items of hl_groups with their highlights applied directly there. For a regular syntax preview there can be a regular split beforehand.

[krovuxdev]

Sounds great! Displaying hl_groups directly in the preview window seems like a solid improvement. I'll try implementing a split, where one side shows the list of hl_groups and the other displays the content with real-time highlighting.

Let me know if you need any input or testing. Thanks for considering my suggestion!

[echasnovski]

Just to be clear, a comment about split was about the user manually opening a file in a vertical/horizontal split with the file which syntax they want to preview. Showing picker should not create any splits.

[pkazmier]

Thanks for the suggestion!

I'll wait about a week for possible @pkazmier availability and then will probably do it myself. Mostly because of the idea you gave about a more informative preview window content. I think it is better to have something like selected items of hl_groups with their highlights applied directly there. For a regular syntax preview there can be a regular split beforehand.

No need to wait for me. I’ve got a queue of coding for work that trumps my personal time for several upcoming weekends. Thanks