Share your setups

[echasnovski]

Seeing how other people use mini.nvim is a very helpful feedback for me. It helps me reason about which modules are used the most and what config values are used. This might influence my future decisions in design and default values. And also might other people new ideas.

Feel free to share a link to specific part of dotfiles (might be a good idea to pin to specific commit), code or screenshot (if too big, please hide under spoiler).

Thanks!

[axpira]

Hi, my config https://github.com/axpira/dotfiles/blob/main/nvim/init.lua

[echasnovski]

Thanks! That is a minimal one indeed :)

Couple of observations:

• require('mini.base16').mini_palette('#112641', '#e2e98f', 75) on its own does almost nothing (initializes module and creates MiniBase16 global table). It returns a default palette. To activate it, save it as palette and use require('mini.base16').setup({palette = palette}) (which I don't think is your intention as you have another colorscheme call).
• require('mini.fuzzy').setup({}) on its own also does almost nothing. It is mainly a collection of functions for one fuzzy matching algorithm. I use it as "easy to understand" and fast algorithm for Telescope matching. See :h MiniFuzzy.get_telescope_sorter().

[xigoi]

require("mini.base16").setup {
  palette = {
    base00 = "#000000",
    base01 = "#111111",
    base02 = "#333333",
    base03 = "#bbbbbb",
    base04 = "#dddddd",
    base05 = "#ffffff",
    base06 = "#ffffff",
    base07 = "#ffffff",
    base09 = "#ff2222",
    base08 = "#ff9922",
    base0A = "#ff22ff",
    base0B = "#22ff22",
    base0C = "#4444ff",
    base0D = "#22ffff",
    base0E = "#ffff22",
    base0F = "#999999",
  },
  use_cterm = false,
}
require("mini.comment").setup {}
require("mini.completion").setup {}
require("mini.jump").setup {
  mappings = {
    repeat_jump = "",
  },
  highlight_delay = 0,
}
require("mini.pairs").setup {}
require("mini.sessions").setup {
  directory = vim.fn.stdpath "config" .. "/sessions",
}
require("mini.starter").setup {
  evaluate_single = true,
}
require("mini.statusline").setup {}
require("mini.surround").setup {
  n_lines = 100,
  mappings = {
    add = "S",
    delete = "ds",
    find_left = "[s",
    find = "]s",
    highlight = "",
    replace = "cs",
    update_n_lines = "",
  },
}
require("mini.tabline").setup {}

[echasnovski]

Thanks, Adam! Some thoughts:

1. That is some real minimal colorscheme. Nice!
2. I am amazed that you are still using 'mini.completion' at its full capabilities. I honestly thought that I've written it entirely for myself (well, apart from signature help, maybe).
3. Glad that evaluate_single in 'mini.starter' is useful to somebody.

[xigoi]

I use mini.completion because I haven't found any completion engine that isn't a pain to setup and has proper Unicode support.

I honestly expected evaluate_single to be the default behavior. It seems intuitive.

[JoseConseco]

I tried to recreate vim startify as close as possible:

local starter = require('mini.starter')
local my_items = {
	starter.sections.builtin_actions(),
	{ name = 'Sessions', action = ":lua require'telescope'.extensions.sessions.sessions{}", section = 'Telescope' },
	{ name = 'Recent Files', action = ':Telescope oldfiles', section = 'Telescope' },
	{ name = 'File Brower', action = ':Telescope file_browser', section = 'Telescope' },
	-- starter.sections.recent_files(10, false),
	-- starter.sections.recent_files(10, true),
	-- Use this if you set up 'mini.sessions'
	starter.sections.sessions(9, true),
	{ name = 'Addons', action = ':e ~/.config/blender/2.82/scripts/addons', section = 'Bookmarks' },
	{ name = 'NvimPlugs', action = ':e ~/.local/share/nvim/site/pack/packer/start', section = 'Bookmarks' },

}
starter.setup({
	-- Whether to open starter buffer on VimEnter. Not opened if Neovim was
	-- started with intent to show something else.
	autoopen = true,

	-- Whether to evaluate action of single active item
	evaluate_single = true,

	-- Items to be displayed. Should be an array with the following elements:
	-- - Item: table with <action>, <name>, and <section> keys.
	-- - Function: should return one of these three categories.
	-- - Array: elements of these three types (i.e. item, array, function).
	-- If `nil` (default), default items will be used (see |mini.starter|).
	items = my_items,

	-- Header to be displayed before items. Should be a string or function
	-- evaluating to single string (use `\n` for new lines).
	-- If `nil` (default), polite greeting will be used.
	header = nil,

	-- Footer to be displayed after items. Should be a string or function
	-- evaluating to string. If `nil`, default usage help will be shown.
	footer = nil,


	-- Array  of functions to be applied consecutively to initial content.
	-- Each function should take and return content for 'Starter' buffer (see
	-- |mini.starter| for more details).
	content_hooks = {
		starter.gen_hook.adding_bullet(),
		starter.gen_hook.indexing('all', { 'Builtin actions', 'Telescope', 'Bookmarks'}),
		starter.gen_hook.padding(5, 2),
		starter.gen_hook.aligning('left', 'top'),
	},

	-- Characters to update query. Each character will have special buffer
	-- mapping overriding your global ones. Be careful to not add `:` as it
	-- allows you to go into command mode.
	query_updaters = [[abcdefghijklmnopqrstuvwxyz0123456789_-.]],
})

[Oliver-Leete]

I had a go at getting mini.ai to work with treesitter text objects. It seems to work alright with the little testing I've done, but I'm sure there are some edge cases that will break this.

Credit for most of the work goes to the nvim-treesitter-textobjects plugin, the textobject_at_point function was taken from there (with a little bit of modification to get the search methods without cover to work properly. I don't think that function doesn't depend on the rest of the plugin so you could use it without having nvim-treesitter-textobjects installed, but it's helpful to have for the queries.

One other thing I added is the ability to use a table of queries instead of just one. Most of the logic was already there, it should just find the best match of any of the given queries.

I'm 99% sure this is more complicated than it needs to be, as I've just kinda smooshed the two things together.

Update

Thanks to the amazing update to the api (seriously, thanks so much @echasnovski), I have massively simplified this to the below function.

My approach does come with the dependency on the nvim-treesitter plugin, but it supports multiple queries in one object and should have full support for all queries defined by nvim-treesitter-textobjects.

local queries = require "nvim-treesitter.query"

local miniAiTreesitter = function(ai_type, _, _, query_list)
    ai_type = ai_type == "a" and ".outer" or ".inner"
    query_list = vim.tbl_map(function(query) return query .. ai_type end, query_list)


    local matches = {}
    for _, query in pairs(query_list) do
        vim.list_extend(matches, queries.get_capture_matches_recursively(0, query, "textobjects"))
    end

    matches = vim.tbl_map(function(match)
        local from_line, from_col, to_line, to_col = match.node:range()
        return {
            from = { line = from_line + 1, col = from_col + 1 },
            to = { line = to_line + 1, col = to_col + 1 }
        }
    end, matches)

    return matches
end

local miniAiTreeWrapper = function(query_list)
    if type(query_list) ~= "table" then
        query_list = { query_list }
    end
    return function(ai_type, _, opts)
        return miniAiTreesitter(ai_type, _, opts, query_list)
    end
end

require("mini.ai").setup({
    custom_textobjects = {
        o = miniAiTreeWrapper({"@block", "@conditional", "@loop"}),
        s = miniAiTreeWrapper({"@function", "@class"}),
        c = miniAiTreeWrapper("@comment"),
    },
})

If I make any further changes to this you should be able to find them here

[echasnovski]

@jonatan-branting, latest main should support array of captures. Not exactly like in this example, but for every a and i objects separately. Thanks for bringing this up!

[Oliver-Leete]

Another quick one, git hunks. This one depends on gitsigns.nvim to get the list of hunks. I think the way I'm getting the hunks is using an internal api, so no guarantees that it won't break without warning. I tried using the gitsigns.get_hunks function but I couldn't find a good way of getting the end line of the hunks from the list that returned. I'm also sure that there is a better way to get the column number for the range end, but this seems to work for now.

local miniAiGitsigns = function()
    local bufnr = vim.api.nvim_get_current_buf()
    local hunks = require("gitsigns.cache").cache[bufnr].hunks
    hunks = vim.tbl_map(function(hunk)
        local from_line = hunk.added.start
        local from_col = 1
        local to_line = hunk.vend
        local to_col = #vim.api.nvim_buf_get_lines(0, to_line-1, to_line, false)[1] + 1
        return {
            from = { line = from_line, col = from_col },
            to = { line = to_line, col = to_col },
        }
    end, hunks)

    return hunks
end

[megalithic]

Question for the ignorant (aka, me); how might you be using this to visually select, say, foo_bar or foo-bar where viw might only see the foo or bar, not foo_bar as a whole word?

Thanks!

[Oliver-Leete]

Question for the ignorant (aka, me); how might you be using this to visually select, say, foo_bar or foo-bar where viw might only see the foo or bar, not foo_bar as a whole word?

Hopefully I'm not misunderstanding. Are you referring to the word object in my config? If so that was taken from the examples in the mini.ai documentation. But you're right, it doesn't include underscores, I've just updated mine by replacing %w with [%w_]. I'm sure there are lots of other cases where it behaves differently from the default object that I haven't realised out yet (and on that I have, it doesn't deal with characters like super and subscripts or Greek letters properly, my next goal is to sort that out)

[megalithic]

🤦 thank you and thank you. i should have dug in further into what those regex patterns. (i loathe regex 🤣)

[mohamad-supangat]

mini.nvim is beautifull one set plugin, here is my setup

https://github.com/mohamad-supangat/nvim-lua/tree/packer

[echasnovski]

Thanks so much!
Can't blame you for preferring 'catpuccin' instead of custom base16 palette :)

[mohamad-supangat]

previously i used base16 template,
https://github.com/mohamad-supangat/nvim-lua/blob/9190dc9bd5e25500c5f3f71d3c406ad2b862343c/lua/plugins/mini.lua#L2

but there are some plugins that are not integrated properly and I haven't had time/time to customize base16 with the plugins I'm using, it's really impressive if all the plugins can be integrated into mini.nvim

[echasnovski]

Yeah, I noticed that :)
That is actually quite a coincidence, as I've already planned to add support for more plugins to 'mini.base16' in the near future.

Do you remember which plugins you were using felt like lacking 'mini.base16' support? It would really help me prioritize which plugins to add.

[mohamad-supangat]

i would love if mini.nvim could integrate easily with some lsp for neovim,

Neovim LSP and DAP
coc.nvim
and Treesitter

I will create a new issue for new features

[JaimeArboleda]

This is my config

It's still a work in progress (I started a couple of days ago, switching from vscode after I decided, finally, to go 100% neovim). So mini is currently 90% of my plugins, if not more. 🤣

This is amazing, I said in reddit and I need to say that again: thank you for this impressive work.

[echasnovski]

Thanks for sharing!

So mini is currently 90% of my plugins, if not more. 🤣

Hope you enjoy this and spread the word about it! This helps a lot.
My goal is to replace all non-language-specific plugins in my personal config, so more things will come.

One suggestion, though: my preference is to supply config settings only if it differs from defaults. It both makes config file more concise and limits possibility of possible breaking changes (which I try to make very rare). There were cases when way of supplying setting changed while preserving default behavior, so nothing was broken if nothing was supplied.

For example, I am writing a big update to 'mini.surround'. It will change some default surroundings, the way custom "input" surroundings are defined, add new search methods, and more. Basically, #103. After that, your comment in 'mini.surround' config will be outdated. Not a big deal, but I hope I made the point.

[JaimeArboleda]

Yes, if I have the opportunity I will help in spreading about this. I think a video will be helpful, somehow, but I am not a youtuber. If only some vim-rock-star could do a video about it...

Regarding your suggestion, I think this is something I copy-pasted when I was starting with the plugin...

Do you mean that adding a table to setup that does not differ from the default is pointless, right?

require("mini.surround").setup(
    {
        -- Add custom surroundings to be used on top of builtin ones. For more
        -- information with examples, see `:h MiniSurround.config`.
        custom_surroundings = nil,
        -- Duration (in ms) of highlight when calling `MiniSurround.highlight()`
        highlight_duration = 500,
        -- Module mappings. Use `''` (empty string) to disable one.
        mappings = {
            add = "sa", -- Add surrounding in Normal and Visual modes
            delete = "sd", -- Delete surrounding
            find = "sf", -- Find surrounding (to the right)
            find_left = "sF", -- Find surrounding (to the left)
            highlight = "sh", -- Highlight surrounding
            replace = "sr", -- Replace surrounding
            update_n_lines = "sn" -- Update `n_lines`
        },
        -- Number of lines within which surrounding is searched
        n_lines = 20,
        -- How to search for surrounding (first inside current line, then inside
        -- neighborhood). One of 'cover', 'cover_or_next', 'cover_or_prev',
        -- 'cover_or_nearest'. For more details, see `:h MiniSurround.config`.
        search_method = "cover"
    }
)

[echasnovski]

Do you mean that adding a table to setup that does not differ from the default is pointless, right?

It doesn't have any effect, yes. Here is my config, for example.

[JaimeArboleda]

Thanks, I have edited my config.

[JaimeArboleda]

An idea that maybe could be of interest of more people:

https://www.reddit.com/r/neovim/comments/x0hf25/nicer_jupyter_notebook_workflow_with_neovim/

[echasnovski]

Nice! Couple of thoughts:

• My gut feeling tells me that the code for aC/iC can be simplified.
• With this kind of structural regions, it is usually more robust to use something that recognizes this structure. In Neovim, this is tree-sitter. Maybe there is a way to define query for cell region?

By the way, I am a data scientist myself. A bit controversial, but I don't really like notebooks. Prefer using terminal window with opened REPL (ipython opened in right virtual environment) side by side with code and then send chunks from source code to terminal. One huge plus I found with this workflow is that output of terminal commands pop up in completion (at least with 'mini.completion').

[JaimeArboleda]

Hey! Thanks for the suggestion!
I am 110% sure that the code can be made simpler and better :D It was my first attemp at writing something in Lua (besides copy/pasting some configs) and it looks very primitive. But well, at least it works!
I've not used tree-sitter yet. It's in my todo list, as well as using LSP. I am going step by step. A week ago I installed LunarVim, that has everything for you out of the box, and nvim was a little bit slow on my machine, so I dediced to do the other way around, and integrate plugins and other things one by one if they don't cause any slow down.
Regarding jupyter notebooks, I think they are super great for 2-3 things:

• Exploratory work (not only exploratory data analsys, but exploratory programming as well).
• For building learning resources. It's very instructive (and easy) to follow a good structured jupyter notebook.
• For sharing insights or even as presentation material (as a replacement of power point).
  For example now I am preparing a series of training sessions for newcomer data scientists and I think that jupyter notebooks are perfectly suited for this. That's why I wanted to have a better workflow within vim. Other than that, I also think they are over used and I work faster with an IDE and a terminal.

[echasnovski]

Sorry, answered in the wrong thread. I've hidden that as off-topic.

[M8850]

Very nice.

(Minimap scrolls to the sides - not necessary.)

[M8850]

dragging the mouse to the side of minimap can cause display corruption,

i'm not sure what causes this

[echasnovski]

Not sure what you mean here. By default map window shouldn't react on mouse clicks. If you set config.window.focusable to true, then it will react as a regular floating window: if you click, it will put cursor there; if you click and drag, it will make visual selection in that window (which is not translated into visual selection of the target buffer, though).

[LkeMitchll]

Mini is my favourite plugin. My neovim setup is minimal, so I really enjoy that I can setup all my mini modules of choice without setting any preferences, because the defaults are just so solid for me. The proof is that I can just loop an array to initialise them.

[Nias26]

You can look at mine in here

[echasnovski]

Nice! Thanks for sharing.

Two immediate things I've noticed:

• These and these lines are the same. There is no need for that.
• Using 'mini.pick' and 'mini.extra' separately from 'mini.nvim' is not necessary as they are already a part of 'mini.nvim'. This leads to unnecessary code duplication.

[Nias26]

Thanks, I copied the loop and forgot to edit it...

As for mini.pick and mini.extra, at first I didn't use them separately from mini.nvim, but when I called setup, it gave me the error mini.extra not found ( same with mini.pick); then I installed them separately as a workaround for it to work.
I was thinking if opening an issue or not, but I want to do some more investigating before opening an issue.

[echasnovski]

As for mini.pick and mini.extra, at first I didn't use them separately from mini.nvim, but when I called setup, it gave me the error mini.extra not found ( same with mini.pick); then I installed them separately as a workaround for it to work. I was thinking if opening an issue or not, but I want to do some more investigating before opening an issue.

Ah, yes. 'mini.nvim' uses version = '*' which is the latest stable version release (0.10.0 at the moment) and does not contain both 'mini.pick' and 'mini.extra'. So yeah, if you want this kind of separation, then the current setup is the way to go. My bad.

[Nias26]

Ah, yes. 'mini.nvim' uses version = '*' which is the latest stable version release (0.10.0 at the moment) and does not contain both 'mini.pick' and 'mini.extra'. So yeah, if you want this kind of separation, then the current setup is the way to go. My bad.

No problem 👍

[EddieFAF]

Here is my setup:
init.lua. It is mainly mini.nvim and lsp/mason.
Since a few days I have some trouble with mini.base16. The text from underlaying window is diplayed weird, eg. the Lazy window and the document in the background:

The border colors for the notify window seem to be both fore- and background to be the same:

The same happens with the buildin themes like minischeme or minicyan :(
I have no idea yet. Other colorschemes like tokyonight are working but I tried to avoid those and stay with mini :/

[echasnovski]

Nice!

Since a few days I have some trouble with mini.base16. The text from underlaying window is diplayed weird, eg. the Lazy window and the document in the background:

This is not a color scheme problem. This looks like an effect of positive 'winblend' option but with notermguicolors. What does :echo &tgc show?

The border colors for the notify window seem to be both fore- and background to be the same:

That was my mistake. Vim's Base16 implementation has VertSplit with same fg and bg colors. Which means that WinSeparator is the same and as it is used as default link for floating window border (FloatBorder), this was displayed. Should be fixed on latest main.

I generally have all 'mini.nvim' modules to have actually visible border (meaning fg and bg colors should be different), but for 'mini.notify' I just copied the links.

Couple of notes:

• This would not have been a problem in current Nightly because I changed the FloatBorder to link to NormalFloat, allowing borders by default.
• I currently use 'mini.hues' ('randomhue' in particular), so 'mini.base16' will have slower reaction time to fix it.

[EddieFAF]

Argh, I'm feeling really dumb now. I'm pretty sure it was working some weeks ago. Was there any change in mini.basics?
After setting termguicolors=true it is working again. Thanks alot for pushing me on the right track :)
Also the border is working after the update, thanks also for this.

[echasnovski]

Argh, I'm feeling really dumb now. I'm pretty sure it was working some weeks ago. Was there any change in mini.basics?

Yes, there was 937386c, but it should only affect Neovim<0.10 (which, I presume, you are using). So not sure what is going on.

[EddieFAF]

I'm using 0.10.0-dev-1588 and 0.10.0-dev-1589, so I should rather look into my terminals :) But as long as I got it working, I'm fine.

[echasnovski]

I'm using 0.10.0-dev-1588 and 0.10.0-dev-1589, so I should rather look into my terminals :) But as long as I got it working, I'm fine.

Ah. I'd suggest to update the version then. It would have fixed both of the issues. Generally, if you have problems using Nightly, first try to use newer version.

[savchenko]

Here is how mini.splitjoin can be enhanced with treesj:

    {   -- Split parameters, simpler version of treesj.lua
        url = 'https://github.com/echasnovski/mini.splitjoin',
        version = '*',
        opts = {
            mappings = {}, -- Configured in treesj => treesitter.lua
            detect = {
                separator = '[,;]'
            }
        }
    },
    { -- Split/Join, integrated with mini.splitjoin
        url = 'https://github.com/Wansmer/treesj',
        dependencies = { 'https://github.com/nvim-treesitter/nvim-treesitter/' },
        keys = {
            { '<leader>m', mode = { 'n', 'v' }, desc = 'Toggle split' }
        },
        config = function()
            local tsj = require('treesj')

            tsj.setup({
                use_default_keymaps = false,
                max_join_length = 512,
            })

            local function get_pos_lang(node)
                local c = vim.api.nvim_win_get_cursor(0)
                local range = { c[1] - 1, c[2], c[1] - 1, c[2] }
                local buf = vim.api.nvim_get_current_buf()
                local ok, parser = pcall(
                    vim.treesitter.get_parser,
                    buf,
                    vim.treesitter.language.get_lang(vim.bo[buf].ft)
                )
                if not ok then
                    return ""
                end
                local current_tree = parser:language_for_range(range)
                return current_tree:lang()
            end

            vim.keymap.set({ 'n', 'v' }, "<leader>m", function()
                local tsj_langs = require("treesj.langs")["presets"]
                local lang = get_pos_lang()
                if lang ~= "" and tsj_langs[lang] then
                    require("treesj").toggle()
                else
                    require("mini.splitjoin").toggle()
                end
            end)
        end
    }

[pkazmier]

I spent this morning tweaking the look of my mini.statusline:

Wide:

Wide with search count:

Less wide:

Narrow:

My changes from the default:

• Created a new filename section to allow separate highlighting of directory and filename. I like to de-emphasize the directory path and emphasize the filename, so it's readily apparent what file I'm editing vs having to parse a whole pathname visually. I recently added the same capability to lazyvim. I also shortened the filename in the same manner that lazyvim does when truncated.
• Removed everything from the default file info section except the file type. It would be nice if one could disable those via options to section.fileinfo.
• Moved the LSP information from the left to the right side. With the extraneous file info removed, this balances the status line better. Plus, my brain just doesn't want LSP info next to Git info for some reason.
• Removed the total cols / rows from section_location when not truncated and instead replaced them with icons, which are eliminated when truncated.
• Uppercased the long-form of the mode name. I think the uppercase forms a nice block that is symmetrical to the block generated by the row / col numbers on the other side. When the mode name was lowercase, it felt uneven to me.
• Added the vertical bar to the right of the search count and added an icon for it too.

I spent a couple hours (yes, sadly), experimenting with lots of other variations:

• Adding icons for each of the diagnostics instead of the E, W, I, and H. Too busy, didn't care for it.
• Adding icons for each of the git indicators instead of +, !, and -. Too busy, didn't care for it.
• Adding different color for each of the above signs. This was a PITA because I wanted to keep the background color of the segment. I'm a lua/vim novice, so maybe it was me, but I just couldn't find a simple way to use the fg of one hl group but leave the bg alone. So I just ended up defining a whole bunch of other hl groups. In any case, it was all for nothing as I found myself preferring the monochromatic look, so I throw all that away.

I love mini.clue and the submodes (post-keys) especially for <C-w>. Excited to throw mini.bracketed into the mix as I think those motions would really benefit from the submodes. I've always found using the bracket motions difficult to quickly type consecutively (maybe because I type in Dvorak?).

I love mini.files, which eliminates any need for a file tree for me. It just feels lightning fast to navigate the filesystem with it. And the UI is beautiful while showing so much context. It was a real pleasure to delete neo-tree from my configuration!

I also enabled mini.notify to replace noice as I feel that's so heavy-handed. Now all that's left to do is fill the bottom left corner of my screen with mini.pick. I'm eager to test this as I'm curious as to how I'll feel without having the preview on the screen at the same time (vs having to <tab> over to it).

The only packages I've tried thus far that I did not care for were mini.pairs and mini.jump2d. I use python often and mini.pairs does not handle docstrings (triple quote), so that was a no-go. There were some other cases where nvim-autopairs seemed better as well.

With regards to mini.jump2d, I found it too busy visually for me. I prefer Folke's flash as my goto jumper.

Overall, love all the hard work you've put into the mini packages. Simply amazing!

[echasnovski]

Thanks for the detailed feedback! It is much appreciated!

Some thoughts:

Removed the total cols / rows from section_location when not truncated and instead replaced them with icons, which are eliminated when truncated.

I can see that people are not really used to having those around. Strangely enough, for me it is quite essential during actual text edit, as I find myself checking this information often.

I spent a couple hours (yes, sadly), experimenting with lots of other variations:

We all have been there :)

... I'm a lua/vim novice ...

All config and thoughts here are very good so far. I think you'll fit nicely in the Neovim users community :)

With regards to mini.jump2d, I found it too busy visually for me. I prefer Folke's flash as my goto jumper.

Understandable. There are other configurations besides default one (which is more or less tailored to what I feel is best) and/or jumping spotter is extensible, if you'll ever got time to tweak the config again.

[pkazmier]

Interesting! I just tested all of them and I really like the single_character as it fits my conditioned flow better where I start with the character of where I want to go. I guess I overlooked these other built-in options.

While I won't make excuses for myself, as a matter of marketing, it might help others if this bullet point in the README

Preconfigured ways of computing jump spots (see help for MiniJump2d.builtin_opts()).

had a few sub-bullets enumerating the other built-ins for others to see what is in the realm of possibility.

The only other functionality that I rely on from Flash is the ability to select treesitter scopes, but that's only because I didn't realize treesitter already had incremental search, which I just discovered thanks to your response to this user inquiring about the same.

So, I'll be removing Flash in favor of Jump2D now. Thanks for the nudge in the right direction with those other built-ins. Great stuff!

[echasnovski]

While I won't make excuses for myself, as a matter of marketing, it might help others if this bullet point in the README

Preconfigured ways of computing jump spots (see help for MiniJump2d.builtin_opts()).

had a few sub-bullets enumerating the other built-ins for others to see what is in the realm of possibility.

Sounds reasonable. This is now live on main branch.

[gallo-s-chingon]

I prefer mini.pick to mini.files with the former all files are listed in a single pane and I can search for filenames. I just wish pick had dev icons to be as pretty as files. but it's a whole lot easier to find files instead of navigating into dirs

[echasnovski]

:Pick files or :Pick explorer allows only to preview and open files, while 'mini.files' allows also files system manipulation (create, delete, rename, copy, move).

I just wish pick had dev icons to be as pretty as files. but it's a whole lot easier to find files instead of navigating into dirs

All :Pick files, :Pick explorer, and 'mini.files' (currently) use the same way of displaying icons: nvim-tree/nvim-web-devicons. If you have it installed and available to use, all entries will have dedicated icons to the left of the item.

[moyiz]

Recently migrated to mini.starter:

Highlights:

Lazy stats (startup time). Currently updated via auto command due to stats not being available when `mini.starter` starts.

    -- Set starter footer and refresh after `startuptime` is available
    vim.api.nvim_create_autocmd("User", {
      pattern = "MiniStarterOpened",
      callback = function()
        vim.api.nvim_create_autocmd("User", {
          pattern = "LazyVimStarted",
          callback = function()
            local starter = require "mini.starter"
            local stats = require("lazy").stats()
            local ms = (math.floor(stats.startuptime * 100 + 0.5) / 100)
            starter.config.footer = function()
              return "⚡ Loaded plugins: "
                .. stats.loaded
                .. "/"
                .. stats.count
                .. "\n⚡ Startup time: "
                .. ms
                .. " ms"
            end
            starter.refresh()
          end,
        })
      end,
    })

A dedicated section for workspaces from `workspaces.nvim`.

    local workspace_items = function()
      local workspaces = require "workspaces"
      local items = {}
      for _, w in pairs(workspaces.get()) do
        table.insert(items, {
          name = w.name .. " " .. vim.fn.fnamemodify(w.path, ":~:."),
          action = "WorkspacesOpen " .. w.name,
          section = "Workspaces",
        })
      end
      return items
    end

A workaround for centralizing header and justifying select sections.

    -- A workaround to centralize everything.
    -- `aligning("center", "center")` will centralize the longest line in
    -- `content`, then left align other items to its beginning.
    -- It causes the header to not be truly centralized and have a variable
    -- shift to the left.
    -- This function will use `aligning` and pad the header accordingly.
    -- It also goes over `justified_sections`, goes over all their items names
    -- and justifies them by padding existing space in them.
    -- Since `item_bullet` are separated from the items themselves, their
    -- width is measured separately and deducted from the padding.
    local centralize = function(justified_sections, centralize_header)
      return function(content, buf_id)
        -- Get max line width, same as in `aligning`
        local max_line_width = math.max(unpack(vim.tbl_map(function(l)
          return vim.fn.strdisplaywidth(l)
        end, starter.content_to_lines(content))))

        -- Align
        content = starter.gen_hook.aligning("center", "center")(content, buf_id)

        -- Iterate over header items and pad with relative missing spaces
        if centralize_header == true then
          local coords = starter.content_coords(content, "header")
          for _, c in ipairs(coords) do
            local unit = content[c.line][c.unit]
            local pad = (max_line_width - vim.fn.strdisplaywidth(unit.string))
              / 2
            if unit.string ~= "" then
              unit.string = string.rep(" ", pad) .. unit.string
            end
          end
        end

        -- Justify recent files and workspaces
        if justified_sections ~= nil and #justified_sections > 0 then
          -- Check if `adding_bullet` has mutated the `content`
          local coords = starter.content_coords(content, "item_bullet")
          local bullet_len = 0
          if coords ~= nil then
            -- Bullet items are defined, compensate for bullet prefix width
            bullet_len = vim.fn.strdisplaywidth(
              content[coords[1].line][coords[1].unit].string
            )
          end

          coords = starter.content_coords(content, "item")
          for _, c in ipairs(coords) do
            local unit = content[c.line][c.unit]
            if vim.tbl_contains(justified_sections, unit.item.section) then
              local one, two = unpack(vim.split(unit.string, " "))
              unit.string = one
                .. string.rep(
                  " ",
                  max_line_width
                    - vim.fn.strdisplaywidth(unit.string)
                    - bullet_len
                    + 1
                )
                .. two
            end
          end
        end
        return content
      end
    end

How it is used in `MiniStarter.setup`.

    starter.setup {
      -- evaluate_single = true,
      header = "███████████████████████████\n"
        .. "███████▀▀▀░░░░░░░▀▀▀███████\n"
        .. "████▀░░░░░░░░░░░░░░░░░▀████\n"
        .. "███│░░░░░░░░░░░░░░░░░░░│███\n"
        .. "██▌│░░░░░░░░░░░░░░░░░░░│▐██\n"
        .. "██░└┐░░░░░░░░░░░░░░░░░┌┘░██\n"
        .. "██░░└┐░░░░░░░░░░░░░░░┌┘░░██\n"
        .. "██░░┌┘▄▄▄▄▄░░░░░▄▄▄▄▄└┐░░██\n"
        .. "██▌░│██████▌░░░▐██████│░▐██\n"
        .. "███░│▐███▀▀░░▄░░▀▀███▌│░███\n"
        .. "██▀─┘░░░░░░░▐█▌░░░░░░░└─▀██\n"
        .. "██▄░░░▄▄▄▓░░▀█▀░░▓▄▄▄░░░▄██\n"
        .. "████▄─┘██▌░░░░░░░▐██└─▄████\n"
        .. "█████░░▐█─┬┬┬┬┬┬┬─█▌░░█████\n"
        .. "████▌░░░▀┬┼┼┼┼┼┼┼┬▀░░░▐████\n"
        .. "█████▄░░░└┴┴┴┴┴┴┴┘░░░▄█████\n"
        .. "███████▄░░░░░░░░░░░▄███████\n"
        .. "██████████▄▄▄▄▄▄▄██████████\n"
        .. "pwd: "
        .. vim.fn.fnamemodify(vim.fn.getcwd(), ":~:."),

      items = {
        workspace_items,
        starter.sections.recent_files(10, false, function(path)
          -- Bring back trailing slash after `dirname`
          return " " .. vim.fn.fnamemodify(path, ":~:.:h") .. "/"
        end),
        { section = "Tools", name = "Lazy", action = "Lazy" },
        { section = "Tools", name = "Telescope", action = "Telescope" },
        starter.sections.builtin_actions(),
      },
      content_hooks = {
        -- starter.gen_hook.adding_bullet(),
        centralize({ "Recent files", "Workspaces" }, true),
      },
    }

PS: adding_bullet is disabled due to a slight shifting to the right that causes misalignment between the header and the items.
Edit: PS: centralize has been fixed to compensate for the width of the bullet prefix. adding_bullet is disabled in this example to reflect the screenshot (that has it disabled).

workspaces.nvim
Current configuration is at https://github.com/moyiz/nvim-config

[echasnovski]

Look very nice! Thanks for sharing!

[moyiz]

@echasnovski Thanks for mini.nvim 💪

I have edited my comment above to include the fix for using centralize with adding_bullet. The issue was that I did not consider bullet width (missed that it is not part of item).

[pkazmier]

Over the past month, I've migrated from LazyVim to a mini-based configuration. It's been a positive experience thanks to the amazing work of @echasnovski and his excellent documentation.

I love mini.pick and its UI design choices. I also wrote a custom picker for my note-taking application, which is where I spend a lot of my day as a manager. I was pleasantly surprised by how much I liked the mini.hues theme. It's become my favorite theme (with a few tweaks). I also switched to mini.deps for package management. The only two mini modules I don't use are mini.completion and mini.pairs.

Link to my full configuration.

[echasnovski]

Very nice config!

It looks fairly close to what I use (except 'mini.completion' and 'mini.pairs', of course :) ). There are plans in motion so that more of plugins from the config can get replaced with 'mini.nvim' module. Stay tuned!

[gallo-s-chingon]

here's my config lua is the devil, it's been a very long journey to get here. on one hand I'm a little bothered everyone seemed to switch to lua during covid. and I was juuuuuust getting the hang of Vimscript.

a lot of trial, error and playing ChatGPT and Perplexity against each other to fix errors with every source / load. I've tried dozens of NeoVim distros, plus hopping around different editors emacs (for about 30 minutes) DOOM emacs, helix, kakoune -it got me to use visual mode before arbitrarily hitting guessing how many words I want to delete 11dw … u …7dw 😑 u 9dw … 😡 u 8dw now v11wbbbd.

even tried org, neorg, fountain, LaTeX (do not recommend unless your book is finished… probably not even then), txt. whatever filetype Final Draft and Scrivner use.

anywho, my last hurrah was kickstarter to figure out this Lua nonsense and sort my plugins per group vs a large headache inducing init trying to figure out what plugin does what I need and do I really need that dependency? apparently so.

So now I'm under 40 plugins, nowhere near the 12 I had with vimscript, but it's a saner and easier to work with prose writing environment… if only I could get snippets to work

[arcxio]

I've been seeking to minimize the number of plugins I use for some time, and mini.nvim has been essential for that, as my setup is mostly based on it now. I use a fair bit of tweaks for my personal workflow here and there, so hopefully this can be helpful!

Here's the mini.nvim portion of my init.lua

local function more_than_one_buffer()
	local seen_first_buf = false
	for _, buf in ipairs(vim.api.nvim_list_bufs()) do
		if vim.bo[buf].buflisted then
			if seen_first_buf then return true else seen_first_buf = true end
		end
	end
	return false
end

local mini_path = vim.fn.stdpath('data') .. '/site/pack/deps/start/mini.nvim'
if vim.fn.isdirectory(mini_path) == 0 then
	local cmd = { 'git', 'clone', '--filter=blob:none', 'https://github.com/echasnovski/mini.nvim', mini_path }
	vim.system(cmd):wait()
	vim.opt.runtimepath:append(mini_path)
end
require('mini.deps').setup()

MiniDeps.later(function() require('mini.bracketed').setup() end)
MiniDeps.later(function() require('mini.completion').setup() end)
MiniDeps.later(function()
	require('mini.hipatterns').setup({
		highlighters = { hex_color = require('mini.hipatterns').gen_highlighter.hex_color() },
		delay = { text_change = 0 },
	})
end)
MiniDeps.later(function()
	require('mini.indentscope').setup({
		draw = { delay = 0, animation = require('mini.indentscope').gen_animation.none() },
		options = { border = 'top' },
		symbol = '│',
	})
end)
MiniDeps.later(function() require('mini.operators').setup() end)
MiniDeps.later(function()
	local function no_icons(buf, items, query) MiniPick.default_show(buf, items, query, { show_icons = false }) end
	require('mini.pick').setup({ source = { show = no_icons } })
end)
MiniDeps.now(function()
	require('mini.base16').setup({
		palette = {
			base00 = '#080808', -- default bg
			base01 = '#121212', -- line number bg
			base02 = '#444444', -- statusline bg, selection bg
			base03 = '#767676', -- line number fg, comments
			base04 = '#eeeeee', -- statusline fg
			base05 = '#eeeeee', -- default fg
			base06 = '#eeeeee', -- light fg (not often used)
			base07 = '#eeeeee', -- light bg (not often used)
			base08 = '#ffd7ff', -- statements, identifiers
			base09 = '#d7afff', -- integers, booleans, constants
			base0A = '#ffffd7', -- classes, search highlights
			base0B = '#afd787', -- strings
			base0C = '#afd7ff', -- builtins
			base0D = '#d7ffff', -- functions
			base0E = '#afffaf', -- keywords
			base0F = '#8a8a8a', -- punctuation, regex, indentscope
		}
	})
	vim.api.nvim_set_hl(0, 'ColorColumn', { link = 'StatusLine' })
end)
MiniDeps.now(function()
	vim.opt.cursorline = false
	vim.opt.foldcolumn = '1'
	vim.opt.splitkeep = 'cursor'
	require('mini.basics').setup({ silent = true })
end)
MiniDeps.now(function()
	require('mini.misc').setup()
	MiniMisc.setup_auto_root()
	MiniMisc.setup_restore_cursor()
	ProjectName = function()
		local root = MiniMisc.find_root()
		return root and vim.fn.fnamemodify(root, ':h:t') .. ' | ' or ''
	end
	vim.opt.statusline = '%{%v:lua.ProjectName()%}' .. vim.o.statusline
end)
MiniDeps.now(function()
	require('mini.sessions').setup()

	local function percent_name(path) return path and path:gsub('/', '%%'):gsub('%%$', '') or nil end

	local command = vim.api.nvim_create_user_command
	command('Sw', function() MiniSessions.write(percent_name(MiniMisc.find_root())) end, {})
	command('Sd', function() MiniSessions.delete(nil, { force = true }) end, {})

	local function autowrite() return vim.v.this_session ~= '' and MiniSessions.write() end
	local function autoread()
		-- return if something is shown
		if vim.fn.argc() > 0 then return end
		if more_than_one_buffer() then return end
		if vim.bo.filetype ~= '' then return end
		if vim.api.nvim_buf_line_count(0) > 1 then return end
		if vim.api.nvim_buf_get_lines(0, 0, 1, true)[1]:len() > 0 then return end

		local session = percent_name(vim.fn.getcwd())
		if vim.tbl_contains(vim.tbl_keys(MiniSessions.detected), session) then MiniSessions.read(session) end
	end

	vim.api.nvim_create_autocmd('VimEnter', { nested = true, once = true, callback = autoread })
	vim.api.nvim_create_autocmd('VimLeavePre', { callback = autowrite })
end)
MiniDeps.now(function()
	local add_sep = require('mini.splitjoin').gen_hook.add_trailing_separator()
	local del_sep = require('mini.splitjoin').gen_hook.del_trailing_separator()
	require('mini.splitjoin').setup({ split = { hooks_post = { add_sep } }, join = { hooks_post = { del_sep } } })
	vim.api.nvim_create_autocmd('FileType', {
		pattern = 'lua',
		callback = function()
			local pad_curly = MiniSplitjoin.gen_hook.pad_brackets({ brackets = { '%b{}' } })
			vim.b.minisplitjoin_config = { join = { hooks_post = { del_sep, pad_curly } } }
		end
	})
end)
MiniDeps.now(function()
	local function format_with_buf_id(buf_id, label) return string.format('%d %s', buf_id, label) end
	require('mini.tabline').setup({ show_icons = false, set_vim_settings = false, format = format_with_buf_id })
	local function set_showtabline() vim.opt.showtabline = more_than_one_buffer() and 2 or 0 end
	vim.api.nvim_create_autocmd('BufEnter', { callback = set_showtabline })
	vim.api.nvim_create_autocmd('SessionLoadPost', { callback = set_showtabline })
end)

[echasnovski]

Thanks for sharing!

Two things that caught my eye:

• I add local now, later = MiniDeps.now, MiniDeps.later and use them without MiniDeps. prefix. This look cleaner somehow.
• I think the more or less established (for now) advice for how to set options from Lua is: use vim.opt only for "list"/"map" like options ('listchars', 'fillchars', etc.) as it has :append() / :remove() methods, and use vim.o for everything else. Using vim.opt for all options is not an error, but vim.o is a more reliable interface.

[ghost]

https://github.com/lyonelzd/.dotfiles/tree/homeyairm1/nvim/.config/nvim

Spent the last few days redoing my nvim dots to center around mini.nvim. It's been fun!

Definitely unnecessary for me to separate every plugin/module into its own little file since most of the mini modules just have one line for calling the .setup() but It's a nice way to see which modules I'm actually using and if I ever wanna add something to the setup I can just go right to the file and modify it.

[echasnovski]

This looks nice! Thanks for sharing!

I like 'kanagawa.nvim' colors, but too bad it doesn't have explicit support for 'mini.nvim' :( My PR got stuck without any feedback. I plan to soon make a second round of adding new 'mini.nvim' highlight groups to popular color schemes. Let's hope it'll get merged in 'kanagawa.nvim'.

[savchenko]

@echasnovski , ever tried modus theme? :)

[echasnovski]

No, I have not. Looking at screenshots, it feels a bit too high contrasty for me. I'll take 'randomhue' any day of the week now, thank you very much :)

[ghost]

This looks nice! Thanks for sharing!

I like 'kanagawa.nvim' colors, but too bad it doesn't have explicit support for 'mini.nvim' :( My PR got stuck without any feedback. I plan to soon make a second round of adding new 'mini.nvim' highlight groups to popular color schemes. Let's hope it'll get merged in 'kanagawa.nvim'.

Oh snap!! I just looked at the PR and translated that to my own dots, moved the overrides to the kanagawa file instead.

kanagawa.lua

require("kanagawa").setup({
      overrides = function(colors)
        local theme = colors.theme
        return {
          MiniCompletionActiveParameter = { underline = true },

          MiniCursorword = { underline = true },
          MiniCursorwordCurrent = { underline = true },

          MiniIndentscopeSymbol = { fg = theme.ui.special },
          MiniIndentscopePrefix = { nocombine = true },

          MiniJump2dSpot = {
            fg = theme.diag.warning,
            bold = true,
            nocombine = true,
          },

          MiniStatuslineDevinfo = { fg = theme.ui.fg_dim, bg = theme.ui.bg_m1 },
          MiniStatuslineFileinfo = { fg = theme.ui.fg_dim, bg = theme.ui.bg_m1 },
          MiniStatuslineFilename = { fg = theme.ui.fg_dim, bg = theme.ui.bg_m3 },
          MiniStatuslineInactive = {
            fg = theme.syn.comment,
            bg = theme.ui.bg_m3,
          },
          MiniStatuslineModeCommand = {
            fg = theme.ui.bg_m3,
            bg = theme.syn.operator,
            bold = true,
          },
          MiniStatuslineModeInsert = {
            fg = theme.ui.bg_m3,
            bg = theme.vcs.added,
            bold = true,
          },
          MiniStatuslineModeNormal = {
            fg = theme.ui.bg_m3,
            bg = theme.syn.fun,
            bold = true,
          },
          MiniStatuslineModeOther = {
            fg = theme.ui.bg_m3,
            bg = theme.syn.deprecated,
            bold = true,
          },
          MiniStatuslineModeReplace = {
            fg = theme.ui.bg_m3,
            bg = theme.vcs.removed,
            bold = true,
          },
          MiniStatuslineModeVisual = {
            fg = theme.ui.bg_m3,
            bg = theme.syn.keyword,
            bold = true,
          },

          MiniTrailspace = { bg = theme.vcs.removed },
        }
end
}

I since added a few other additions to my setup like bracketed and animate. Mini is taking over lol. Will keep on the lookout for the kanagawa integration round two and for mini.snippets!!

[lostl1ght]

I've been having a blast tinkering with mini.deps. So I want to share my init.lua and directory structure:

init.lua

vim.loader.enable()

vim.g.loaded_gzip = 1
vim.g.loaded_tar = 1
vim.g.loaded_tarPlugin = 1
vim.g.loaded_zip = 1
vim.g.loaded_zipPlugin = 1
vim.g.loaded_getscript = 1
vim.g.loaded_getscriptPlugin = 1
vim.g.loaded_vimball = 1
vim.g.loaded_vimballPlugin = 1
vim.g.loaded_matchit = 1
vim.g.loaded_matchparen = 1
vim.g.loaded_spellfile_plugin = 1
vim.g.loaded_2html_plugin = 1
vim.g.loaded_logiPat = 1
vim.g.loaded_rrhelper = 1
vim.g.loaded_netrw = 1
vim.g.loaded_netrwPlugin = 1
vim.g.loaded_netrwSettings = 1
vim.g.loaded_netrwFileHandlers = 1
vim.g.loaded_tutor_mode_plugin = 1

local path_package = vim.fn.stdpath('data') .. '/site/'
local deps_path = path_package .. 'pack/deps/start/mini.deps'
if not vim.uv.fs_stat(deps_path) then
  if vim.fn.executable('git') == 0 then
    vim.api.nvim_echo({
      { 'git is not installed\n', 'ErrorMsg' },
      { 'Press any key to exit...', 'MoreMsg' },
    }, true, {})
    vim.fn.getchar()
    vim.cmd('quit')
  end
  vim.api.nvim_echo({ { 'Installing `mini.deps`', 'WarningMsg' } }, true, {})
  vim
    .system({
      'git',
      'clone',
      '--filter=blob:none',
      '--single-branch',
      'https://github.com/echasnovski/mini.deps',
      deps_path,
    })
    :wait()
  vim.cmd('packadd mini.deps')
  vim.cmd('helptags ALL')
  vim.api.nvim_echo({ { 'Installed `mini.deps`', 'MoreMsg' } }, true, {})
end

local ok, MiniDeps = pcall(require, 'mini.deps')

if not ok then
  vim.api.nvim_echo({
    { ('Unable to load `mini.deps` from: %s\n'):format(deps_path), 'ErrorMsg' },
    { 'Press any key to exit...', 'MoreMsg' },
  }, true, {})
  vim.fn.getchar()
  vim.cmd('quit')
end

MiniDeps.setup({ path = { package = path_package } })
vim.g.border = 'single'

local now = MiniDeps.now
for f in vim.fs.dir(vim.fn.stdpath('config') .. '/lua/config') do
  now(function() require('config.' .. vim.fn.fnamemodify(f, ':r')) end)
end

for f in vim.fs.dir(vim.fn.stdpath('config') .. '/lua/plugin') do
  require('plugin.' .. vim.fn.fnamemodify(f, ':r'))
end

lua/
|- plugin/
|  |- completion.lua
|  |- lsp.lua
|  |- ...
|- config/
|  |- keymap.lua
|  |- autocmd.lua
|  |- ...
init.lua

lua/plugin directory is for plugin spec definitions and their configs (now/add/setup or later/add/setup).
Each file there is more of a group of these definitions because sometimes order matters (like 'nvim-autopairs' has to be loaded before 'nvim-cmp').

lua/config directory is for configs that don't require any plugins (auto commands, key mappings, etc.). The reason behind loading these files manually and not putting them into native plugin directory is that neovim seems to load these files at whatever time and sometimes auto commands did not fire when I tried to open a file.

Now adding or removing a plugin is just a matter of adding/removing a file in lua/plugin directory. The loop at the end of init.lua will take care of loading it.

Also, I was surprised that loading all the 50+ plugins at the (basically) startup instead of loading a third of them and the rest at specific events (like I did with folke's 'lazy.nvim') did not increase startup time. At least I do not notice that.

Bonus, a helper function to notify when building a plugin post-installation starts and ends (and how it ends):

build_package()

---@param cmd string[]
---@param spec {path:string,name:string,source:string}
M.build_package = function(cmd, spec)
  local levels = vim.log.levels
  vim.notify(('(mini.deps) Building `%s`'):format(spec.name), levels.INFO)
  vim.system(cmd, { text = true }, function(obj)
    local msg = ''
    local lvl = levels.INFO
    if obj.code ~= 0 then
      lvl = levels.ERROR
      msg = ('\nCode %d\n%s'):format(obj.code, obj.stderr)
    end
    vim.schedule(
      function() vim.notify(('(mini.deps) Finished building `%s`%s'):format(spec.name, msg), lvl) end
    )
  end)
end

All in all, mini.deps is an amazingly designed plugin manager with only ~800 LoC. Thank you, @echasnovski !

[echasnovski]

Thanks for kind words! Glad you are enjoying 'mini.deps'.

It is also great that you found a directory structure that works for you. When I redid my config prior to 'mini.deps' I ended up with using separate 'src/' directory outside of 'lua/'. The reason for this is that this makes :source of 'init.lua' reload all settings/mappings/plugin setups, etc. Here is the repo for reference.

[wroyca]

I thought I’d share mine now. It’s a bit rough around the edges, but it has grown organically, and I’ve become really comfortable with it. The current structure makes it easy for me to add new plugins and see if they fit into my workflow. Overall, it’s nothing fancy—just pretty basic.

One cool thing (though still a work in progress) is the Emacs <-> Neovim integration for Magit, which also integrates with RandomHue on the fly.

https://github.com/wroyca/dotfiles/tree/main/dot_config/nvim

[echasnovski]

Thanks for sharing!

This looks very thought through. A bit complex for my taste, but everybody is different :)

Rescheduling loading shada is a nice touch, but I think it might break plugins which depend on it during startup (although there is a listed 'mini.starter', so I am not sure if it is true in this case).

Reading shada file can indeed be a source of a large startup delay, which is mostly fixed by limiting the number of history entries (like search patterns, commands, user inputs) it stores. Limiting from default 10000 to 100 greatly reduces startup time. I personally use this approach vim.o.shada = "'100,<50,s10,:1000,/100,@100,h".

[wroyca]

Rescheduling loading shada is a nice touch, but I think it might break plugins which depend on it during startup (although there is a listed 'mini.starter', so I am not sure if it is true in this case).

Correct—it breaks dashboard-type plugins like mini.starter, alpha, startify, and so on. Most of these have a refresh (redraw) command, though, so I've added vim.cmd.doautocmd "User ShadaLoadPost" for that purpose. It’s not perfect, but I didn’t spend too much time figuring out a solution since I don’t use dashboard plugins to begin with. ;)

I also have to admit that I'm growing increasingly frustrated with ShaDa as a whole—it often gets tainted by junk and invalid buffers. We can skip some of this with shada^=rfoo, but it's a subpar solution. There are some proposed drafts, such as this one, but nothing concrete enough to use reliably.

At some point, I need to figure out a better way to handle my jumplist. Visits sound lovely for that, but I admittedly haven’t gotten around to the slightly higher mental overhead compared to just using Ctrl+i/Ctrl+o. Perhaps I'll get around to it eventually. :)

In any case, feel free to AMA about the configuration!

[abeldekat]

I already posted parts of my config in the "show and tell" section. Recently I finished all "todos" and refactored a few hacks into proper solutions. Thanks for creating mini.nvim!

https://github.com/abeldekat/nvim_pde

Most of the plugins are now from mini.

[echasnovski]

Beautiful and nicely documented config!

[abeldekat]

Thanks for the feedback. Very much appreciated!

[231tr0n]

Hi everyone. I just created a webpage in my personal website showcasing my neovim configuration and explaining how I migrated all the way from vim to neovim and switched most of the stuff to mini.nvim. Please do check it out and let me know how do you feel about it.

Below is the link for the webpage.

https://231tr0n.github.io/blog/config

Below is the link for my neovim configuration.

https://github.com/231tr0n/config/blob/main/nvim/init.lua

Here are a few screenshots of it

[231tr0n]

Also I don't use mini.pick in favour of fzf-lua since I tried it initially and could see few performance issues with mini.pick and telescope on files which are big horizontally. And that is to be expected since both mini.pick and telescope are written in lua while fzf is written in go which is a compiled language.

What kind of performance issues? And what does it have to do with "files which are big horizontally"? Matching speed of 'mini.pick' and 'fzf-lua' is pretty comparable in my tests.

Hence after finding out that I don't use 10 of them, I approached the thought process of why to load code which I am not using and hence went with the standalone ones.

This can only make sense if by "load the code" you mean "_down_load the code". Otherwise module's code is executed only after calling its setup() function. There is no performance implications of having the whole 'mini.nvim' and not using some modules. In fact, when talking about 30 separate plugins, it might be even better to use single 'mini.nvim' as it only adds single Neovim runtime path entry (which are used to search for modules at every require() call, for example) instead of 30.

For the first question, the problem I faced was not matching speed but the UI speed. So the thing is when the lines are way too big like in the case of output files from rollup for sveltekit, the UI seems to take a lot of time to move between different entries when in preview mode. Also, overall I felt like how the entries are shown in fzf with multi line are way clearer as in the below picture.

For the second question, now that I read your message it actually makes sense, I taught whenever mini.nvim loads, each lua module is added using the packadd command which I felt like unecessary but now that I read your message it actually makes sense. I will switch it back to bundling entire mini.nvim.

[echasnovski]

For the first question, the problem I faced was not matching speed but the UI speed. So the thing is when the lines are way too big like in the case of output files from rollup for sveltekit, the UI seems to take a lot of time to move between different entries when in preview mode.

If you can create a reproducible example (as small as possible, please; without the need to use sveltekit), I'll take a look at what causes it. Chances are, it is indeed the result of how preview is done. But who knows.

[231tr0n]

For the first question, the problem I faced was not matching speed but the UI speed. So the thing is when the lines are way too big like in the case of output files from rollup for sveltekit, the UI seems to take a lot of time to move between different entries when in preview mode.

If you can create a reproducible example (as small as possible, please; without the need to use sveltekit), I'll take a look at what causes it. Chances are, it is indeed the result of how preview is done. But who knows.

Sure I will try raising a issue on this. I wanted to do it at that time. I just forgot ig. Also just wanted to ask if it is in scope of mini.nvim to use fzf as the backend UI instead of mini.pick for all the pickers provided. Is that doable @echasnovski. If this is doable, I can knock of entire fzf-lua with just mini.pick.

[echasnovski]

Also just wanted to ask if it is in scope of mini.nvim to use fzf as the backend instead of mini.pick for all the pickers provided. Is that doable @echasnovski. If this is doable, I can knock of entire fzf-lua with just mini.pick.

In theory, any part of picker specification can be customized. For example, use fzf as matching backend. However, it is not worth it, in my opinion. Matching performance of built-in default is on par with fzf.

Don't get me wrong, 'fzf-lua' is a great plugin with an awesome author/maintainer. If you feel like it suits your needs better - use it.

[231tr0n]

The only thing I feel is really great about fzf than mini.pick is that it shows the entries very neatly. That and the above issue of performance was my only concern. Nothing else.

[masroof-maindak]

https://github.com/masroof-maindak/nvim

I would love some feedback on this (particularly if there's a better way to handle certain things like my base16 & statusline setups...

[echasnovski]

Very nice! (ASCII art and wizard pug especially :) )

I don't see any obvious problems with either base16 or statusline setups. Maybe these nit picks:

• The palette here will always be defined (at least at the moment, 'background' is always one of "dark" or "light"). If anything, there can be if palette == nil then error('Could not compute palette') end early stop with other code proceeding not inside if ... end.
• This line seems to be out of place, as there are other hi() usages.
• The sequential if ... else in 'mini.statusline' setup are fine, although to my taste I'd write them like this (which clearly shows the nested decision structure; using nested if .. else is also fine):

  local devinfo
  if git == '' then
    devinfo = diff == ' -' and '' or diff
  else
    devinfo = git .. (diff == ' -' and ' ' or (' │' .. diff))
  end

[masroof-maindak]

Much appreciated, thanks bro.