Ask questions

[echasnovski]

This discussion is closed and locked for reasons described in this comment. Please create a separate "Q&A" discussion to ask a question.

[pyrox0]

Could you add docs on how I can use mini.pairs or mini.surround with completion plugins such as coq_nvim or cmp-nvim? The windwp/nvim-autopairs plugin provides instructions for using it with these plugins (see https://github.com/windwp/nvim-autopairs#mapping-cr). Is there any way to do this with mini.pairs and mini.surround? Thanks!

[echasnovski]

I am not sure if it will be specifically for coq_nvim, but i planned to document a possible way of mapping <CR>, <Tab>, and <S-Tab>. Are these mappings you are interested about?
Can't see how mini.surround and completion plugin can interfere with each other. What kind of troubles do you have here?

[pyrox0]

I'm not using mini.nvim right now, and I've never used something like mini.surround, so I wanted to make sure that it wouldn't conflict with my completion plugin. If you documented how to integrate mini.nvim with coq_nvim, then I would 100% switch to it so I could replace a bunch of plugins with just one!

[txtyash]

How to disable few mini.surround commands?

  mappings = {
    add = 'ys',           -- Add surrounding
    delete = 'ds',        -- Delete surrounding
    find = 'ysf',          -- Find surrounding (to the right)
    find_left = 'ysF',     -- Find surrounding (to the left)
    highlight = 'ysh',     -- Highlight surrounding
    replace = 'cs',       -- Replace surrounding
    update_n_lines = 'ysn' -- Update `n_lines`
  }

I don't want find_left, highlight, update_n_lines.. commands. I wanted to free
s but I still don't want to those commands with y.

[echasnovski]

To not create one or several mappings, use empty string ('') for them.

I put this information in the comment just above mappings section in default config (-- Mappings. Use `''` (empty string) to disable one.). Where do you expect this information to be put for better discoverability?

[Boggin]

Trying to set up on Windows 10 with packer.nvim and each time I try to use the commands, i.e. sa, it does a substitute instead.

nvim v0.5.0

init.vim

lua require('plugins')

plugins.lua

return require('packer').startup(function()  
  use 'wbthomason/packer.nvim'  
  use {   
	  'echasnovski/mini.nvim',  
	  branch = 'stable',  
	  setup = [[require('mini.surround')]],  
  }  
 end)  

Any ideas what I need to do would be gratefully received! Thanks.

[echasnovski]

In order to "activate" this module, you have to call its setup() function with your config table (or nothing to use default config). So in your case it should be enough to use this line instead of a posted one:

setup = [[require('mini.surround').setup()]],  

[Boggin]

Thanks for that. Working now!

It was also that I'd not read a note on packer.vim. I'll copy it here in case someone else has made the same mistake:
"If you are on Windows 10, you need developer mode enabled in order to use local plugins (creating symbolic links requires admin privileges on Windows - credit to @TimUntersberger for this note)"

[IlyaKisil]

How to make visual selection dot-repeatable with mini.surround? For example, with this mapping

vim.api.nvim_set_keymap('x', 'S', [[:<C-u>lua MiniSurround.add('visual')<CR>]], { noremap = true })

if I select some text in visual mode and then S" this will surround selection with double quotes. But I'd like to repeat this action with . for the other selection.

[echasnovski]

Unfortunately, not possible at the moment. Couple of reasons:

• In my experience, visual mode operations are not really intended to be dot-repeatable. Operations with text objects and motions - are. I understand that it is possible in the way that you describe, just doesn't seem to be widely implemented and used.
• If I remember correctly, originally it was somewhat difficult to make properly due to module design.

[IlyaKisil]

How to repeat jump mini.jump but backwards? For example, with vanilla config

• ; Repeat latest f, t, F or T [count] times
• , Repeat latest f, t, F or T in opposite direction [count] times
  mini.jump config exposes mapping for the forward jump

{
  mappings = {
    ...
    repeat_jump = ';',
  }
}

I've quickly looked through jump.lua and it doesn't look like there is such option or does it 🤷 ?)

[echasnovski]

Yes, there is no builtin option for that. Is it a real inconvenience to swap f (F) for t (T) manually?

There is a MiniJump.state that tracks state of recent jump. Should be possible to write one wrapper. Something like lua MiniJump.jump(nil, not MiniJump.state.backward), maybe?

[IlyaKisil]

Is it a real inconvenience to swap f (F) for t (T) manually?
It is not about swapping them in the config, it is about not re-initiating jumps if you overshoot.

For instance, let's say that you did fo;;;;;;; and then you realised that you over jumped by three positions and need to go three positions back.

vim.api.nvim_set_keymap('n', ',', [[:<C-u>lua MiniJump.jump(nil, not MiniJump.state.backward)<CR>]], { noremap = true })
vim.api.nvim_set_keymap('n', ',', [[:<C-u>lua MiniJump.smart_jump(not MiniJump.state.backward)<CR>]], { noremap = true })

This wouldn't work, as it will just get stuck in a loop, since update_state will be reusing state for subsequent jumps.

However, the following two mappings

vim.api.nvim_set_keymap('n', ',', [[:<C-u>lua MiniJump.jump(nil, true)<CR>]], { noremap = true })
vim.api.nvim_set_keymap('n', ',', [[:<C-u>lua MiniJump.smart_jump(true)<CR>]], { noremap = true })

kinda work, but they would break switch to ;. So in general, , should be considered in a sense of reversing direction of jumps. For instance:

• Instead of using ,,, (go 3 times backwards) it is better to do ,;; (, -> reverse direction and then ;; repeat 2 jumps in that reversed direction).
• Then if you over jumped backwards again, you would need to do , to start going forward and however many times ; to keep going forward, i.e. repeating jumps.

Note, that if you just use ,,, then you lose ability to go forward without re-initiating search with f, as ; will just continue to go to the reversed direction.

Since this is not ideal, so there is a need for wrapper. Here is what I came up with.

local M = {}

function M.repeat_in_oposite_direction()
  local state = {}
  for k, v in pairs(MiniJump.state) do
    state[k] = v
  end
  MiniJump.smart_jump(not MiniJump.state.backward)
  MiniJump.state = state
end

vim.api.nvim_set_keymap('n', ',', [[:<C-u>lua require("<this-module>").repeat_in_oposite_direction()<CR>]], { noremap = true })

return M

This seems to work with f and F just fine, and it will also replicate revert in opposite directions for t or T like in the plain (N)Vim config. But assume that you do to;;; which will stop as shown below

aaaa o aaaaa o aaaa o aaaa o
    ^       ^      ^      ^

But if you over jump and want to go backwards, it will stop after o

aaaa o aaaaa o aaaa o aaaa o
      ^       ^      ^      ^

whereas, I'd like it to just go backwards of the same positions. However, I guess this is outside of scope of this plugin.

[echasnovski]

This wouldn't work, as it will just get stuck in a loop, since update_state will be reusing state for subsequent jumps.

Yeah, you are right.

Basically, lack of intuitiveness (what should jumping in reverse three times be: ,,, or ,;;, etc.) and "symmetry" issues (it reverses direction, but there is also till) that "reverse jump" brings prompted me to not include it in module.

For instance, let's say that you did fo;;;;;;; and then you realised that you over jumped by three positions and need to go three positions back.

The designed way of doing this would be fofffffff and then going three times earlier with 3F.

Since this is not ideal, so there is a need for wrapper. Here is what I came up with.

Nice! Here is how I would write this:

function M.opposite_jump()
  MiniJump.state.backward = not MiniJump.state.backward
  MiniJump.smart_jump()
  MiniJump.state.backward = not MiniJump.state.backward
end

However, I guess this is outside of scope of this plugin.

It is indeed, yes.

[IlyaKisil]

For instance, let's say that you did fo;;;;;;; and then you realised that you over jumped by three positions and need to go three positions back.

The designed way of doing this would be fofffffff and then going three times earlier with 3F.

Ohhh... I didn't realise that fofffffff would work. Although I've watched show-case video but it still didn't settle in my head. I think, I like your design decision of first doing [fFtT]<letter> and then just using [fFtT] instead of ;, to repeat jumps

Initially, I thought this plugin is mainly to replicate default fFtT with default mappings for repeating actions, i.e. ; and ,

• With an option of going across lines
• Being written in Lua

I guess, I got confused by having this option customisable.

repeat_jump = ';',

What is the point of having this if you can essentially repeat jump with either ftTF after the initial fo?

[echasnovski]

Ironically, original author of module wasn't a fan of this option. My motivation behind this was twofold:

• It might be useful for people who don't want to "loose muscle memory of original Vim commands", which can be useful outside of Neovim (like in command line with vi keybindings). I initially used it myself, but after some time found myself using ftFT to repeat.
• It had natural implementation within current design and didn't add much complexity.

[shashanktomar]

Hi, thanks for an amazing plugin. Really appreciate the effort put into documenting everything.

What is the easiest way to map mini.ai function_call mapping to something other than f. Is this the only way to do this?

   custom_textobjects = {
    c = gen_spec.function_call({ name_pattern = '[%w_%.]' }),
    f = spec_treesitter({
      a = '@function.outer',
      i = '@function.inner',
    }),
  },

[echasnovski]

Thanks for kind words!

What is the easiest way to map mini.ai function_call mapping to something other than f. Is this the only way to do this?

Your example setup already uses c to select function call (based on Lua patterns; allows alphanumeric, underscore, and dot to be inside function name) and f to select function definition (based on tree-sitter).

Alternatively, you can use tree-sitter to select function call (has both pros and cons), which can be achieved with this:

local gen_spec = require('mini.ai').gen_spec
require('mini.ai').setup({
  custom_textobjects = {
    c = gen_spec.treesitter({ a = '@call.outer', i = '@call.inner' }),
    f = gen_spec.treesitter({ a = '@function.outer', i = '@function.inner' }),
  },
})

[shashanktomar]

Hi There Again,

I am currently using Comment.nvim but want to give mini.comment a try. The documentation says:
Not supported - Block and sub-line comments. This will only support per-line commenting.

Is there any plan to add block level commenting anytime in the future or it will never be supported.

[echasnovski]

... missing triple backticks in "mini.surround", etc. which make them unusable for me.

If you did mean 'mini.surround', then you can define them in config.custom_surroundings via something like { input = { '```().-()```' }, output = { left = '```', right = '```' } }.

If you meant 'mini.pairs', then yeah, I do at the moment think that it is not the place for this kind of functionality there. It is better suited for snippets, which I hope will be implemented in future 'mini.snippets'.

[txtyash]

Yea, i prolly meant mini.pairs. btw, the one major thing that is missing is gifs for every module in the readme. That'd be really great.

[echasnovski]

... the one major thing that is missing is gifs for every module in the readme. That'd be really great.

They were in README (well mp4, not gif) but file got too big to load which is bad for the main page of plugin. They now are in a separate DEMO.md with links to it inside every module's section in main README. I am currently in the process of reorganizing documentation, so there will be separate READMEs for every module with links to them in main one.

[gibfahn]

If you did mean 'mini.surround', then you can define them in config.custom_surroundings via something like { input = { '().-()' }, output = { left = '', right = '' } }.

Came here looking for a surround option for Markdown code blocks, does this handle newlines? e.g I want to surround the current line with backticks like:

Before:

foo()

After:

```
foo()
```

ideally with an optional codeblock syntax, or at least leaving the cursor at the end of the first set of backticks so you can easily type the language. For comparison here's how you do it in nvim-surround.

Fair enough if that's out of scope for the plugin, just wondered whether I was missing something looking at the setup docs.

[echasnovski]

Came here looking for a surround option for Markdown code blocks, does this handle newlines?

It can be made to, because new lines are respected (with a caveat).

I would do that by creating (in config directory) a 'after/filetype/markdown/lua' file with the following content:

vim.b.minisurround_config = {
  custom_surroundings = {
    c = { input = { '```\n().-()\n```' }, output = { left = '```\n', right = '\n```' } },
  },
}

The caveat here is that this will work only if first line has zero indent. If not, ``` will be inserted after that indent and the first line in code block will have zero indent. Not sure if this will change, as it works for majority of cases.

[konart]

Hi! Thanks for a great toolkit.

mini.surround question here:

Is it possible to surround en element (or by motion) with function call? Based on the readme I'd think I can do something like:

a := "so|me_string" //  `|` is the cursor position.

safW( and have is surrounded with () with cursor before the leftmost ( or something like that.

But I can't really figure this out.

[echasnovski]

Hello! Thanks!

Adding surrounding is done in three steps:

• Initiate "Add surrounding" action via sa.
• Tell what region you want to surround via textobject or motion. For example, in your example it can be "around "" which is a".
• Tell which surrounding you want to add via pressing single character surrounding identifier. For a function call, it is f. It will prompt you to insert function name: type it (if I understood correctly, you want W as a function name) and hit <CR> (Enter).

So, overall sequence on characters you need to press is: saa"fW<CR> (<CR> is single hit on Enter). This will result into following state:

a := W(|"some_string")

I am not sure I have 100% understanding of your question, though. Does this help you figure it out?

Here are some other examples.

[megalithic]

👋 hi @echasnovski; LOVE your work and plugins. Question regarding mini.pairs; I'm looking to move to mini.pairs instead of nvim-autopairs; one thing I'd love to ensure is possible, is the ability to handle endwise matches (aka, lua's then..end, or function() end, etc.; or ruby/elixir's do..end, etc.).

Hopefully this isn't too far out of the realm of possibility (oh, and of course, compatibility with nvim-cmcp).

Thanks!

[txtyash]

👋 hi @echasnovski; LOVE your work and plugins. Question regarding mini.pairs; I'm looking to move to mini.pairs instead of nvim-autopairs; one thing I'd love to ensure is possible, is the ability to handle endwise matches (aka, lua's then..end, or function() end, etc.; or ruby/elixir's do..end, etc.).

Hopefully this isn't too far out of the realm of possibility (oh, and of course, compatibility with nvim-cmcp).

Thanks!

U shudve mentioned triple backticks

[echasnovski]

@megalithic, as you already found a #9, my suggestion is to use snippet engine for these cases. 'mini.pairs' is designed to work with single character left and right parts, and it will be that way (at least, for a while).

[bangedorrunt]

Hi @echasnovski, I'm wondering why mini.completion doesn't come with LSP snippet support?

[echasnovski]

Hi! Mostly because it has complicated implementation. 'mini.completion' is already quite big and complex, so I don't want to overburden it.

[bangedorrunt]

Hi! Mostly because it has complicated implementation. 'mini.completion' is already quite big and complex, so I don't want to overburden it.

I'm aware of the purpose of mini.nvim, but at least for me, trying to make a minimalistic plugin doesn't mean we have to trip off essential features. I think snippet engine is very important and should be a complement to LSP servers. I understand that this means more burden on your shoulder. My suggestion is you might make other plugin such as mini.snip which is complement to mini.completion.

[echasnovski]

Thank you for your suggestion. It is already planned.

[bangedorrunt]

Awesome, couldn't wait! Thank you a tons

[GllmR]

Is there a way to have transparent background in mini.starter ?

[echasnovski]

The background in 'mini.starter' is the same as background in all other windows. It is a Normal highlight group. Usually needs a transparent terminal emulator and hi Normal guibg=NONE somewhere.

Do you have working transparent background for other windows but still have 'mini.starter' open without transparency? Or do you want only Starter buffer to be transparent?

[GllmR]

Ok, sorry, it's another plugin that make the background dark (drop-nvim)
🙇

[galli-miro]

Hi!

I've recently started using mini.comment instead of tpope implementation. The one thing annoying sometimes, is that when I'm trying to comment an entire paragraph with gcap, it also comments the empty line at the end of it. If I were to use dot repeat to revert the change, it instead comments the same paragraph again, as well as the next one.

nvim-comment solved this by adding an option to ignore empty lines. Is this something that mini.comment might also have someday?

[echasnovski]

Hi!

US there any reason to not use gcip? It doesn't select empty lines and can be reverted with ..

[galli-miro]

Aah, you are absolutely right. I don't know why I didn't think about that. Thanks :)

[madjxatw]

It is possible to set rules for mini.pairs like nvim-autopairs does? E.g. I probably don't expect a pair of quotes to be inserted when the cursor is right before a word (|word). I used https://github.com/jiangmiao/auto-pairs and https://github.com/tmsvg/pear-tree before with Vim and I prefer the latter as its default behavior makes more sense to me.

[echasnovski]

The only "rules" 'mini.pairs' supports is conditioning on cursor's neighborhood. So you can set up to insert pair only if cursor's neighborhood matches some two-character neigh_pattern Lua pattern. You can do this either inside config for built-in characters or inside MiniPairs.map() for manual mapping.

You case is thus can be supported with this setup:

require('mini.pairs').setup({
  mappings = {
    ['"'] = { neigh_pattern = '[^\\]%W' },
  }
})

Here it will insert "" only if previous character is not a \ and next character is not an alphanumeric character. See here for more special Lua patterns.

[madjxatw]

But how can I distinguish left neighbor and right neighbor?

[echasnovski]

It is a two-character pattern: first character matches left neighbor, second - right.

[madjxatw]

Got it, I misunderstood the concept of 2-chars a bit before, thanks a lot for the explanation with useful links!

[madjxatw]

Excuse me, another question is how to set up mini.pairs to correctly handle Markdown triple ticks. Now whenever I press ` twice, it produces four `.

[echasnovski]

Unfortunately, there is no way right now and probably won't be. The reason is that 'mini.pairs' is designed to work only for two-character neighborhood. Anything wider is a functionality more suited for snippets, in my opinion.

[RyanzpLee]

Dumb question, but how do I get mini.sessions to work? I've installed the module along with starter. Do I have to type in :lua MiniSessions.write({ name of my session }) or do I setup a keybind? What is a recommended approach to get up and running quickly please!

[echasnovski]

I tried to make a keymap that would let me type in the session name, but the session name ended up being table: 0x0102e019283. Any ideas why it's not working? keymap("n", "<leader>msw", [[ :lua MiniSessions.write({ vim.fn.input("Session Name > ") })<CR> ]])

The MiniSessions.write() takes a string as session name in first argument. You have { ... } which creates a table.
Try this: vim.keymap.set("n", "<leader>msw", '<Cmd>lua MiniSessions.write(vim.fn.input("Session Name > "))<CR>').

Also I tried doing :lua MiniSessions.detected() to see what sessions are available and expected a list to come back, but I get back this error. Am I using it wrong?

E5108: Error executing lua [string ":lua"]:1: attempt to call field 'detected' (a table value)
stack traceback:
        [string ":lua"]:1: in main chunk

The MiniSessions.detected is already a table with detected sessions. To see them, try :lua =MiniSessions.detected if you are on Neovim>=0.8.2 or :lua print(vim.inspect(MiniSessions.detected)) otherwise.

Thanks for your awesome plugins btw

❤️

[name-jerry]

How do I create a global session?

[Klvxn]

One way is to set file option to an empty string to disable local sessions.

require('mini.sessions').setup({ file = '' })

[echasnovski]

How do I create a global session?

Execute MiniSessions.write('session-name') where 'session-name' should be not the string used for local sessions ('Session.vim' by default, configured via config.file).

After that, you can read that session with MiniSessions.read('session-name').

[name-jerry]

How do I create a global session?

Execute MiniSessions.write('session-name') where 'session-name' should be not the string used for local sessions ('Session.vim' by default, configured via config.file).

After that, you can read that session with MiniSessions.read('session-name').

thank you

[fresh2dev]

I am a fan of both mini.surround and mini.pairs.

When coding in Python, I am often found turning text like this...

var: int,

...into this...

var: Optional[int],

I always find myself typing Optional first, then creating the pairs, which creates a mental mess. I'm trying to retrain my approach to first add the brackets, then add Optional.

Is there a simpler way to approach this using mini.surround and mini.pairs?

[fresh2dev]

I'm thinking off something that would allow me to stay in insert mode and type:

Optional|int then press a mapping (say, <C-s>) and enter a motion for the surround.

So, then Optional + C-s + w to turn int into Optional[int].

I guess I could get more comfortable using <C-o> as well.

[echasnovski]

If this happens occasionally, I'd suggest creating a surrounding from user prompt. So that would be:

• Put cursor on int in Normal mode.
• Type saiw?.
• Type Optional[ and <CR> for the left part.
• Type ] and <CR> for the right part.

If you encounter this often (as I assume you do :) ), I'd suggest "investing" into creating custom surrounding. As it is a name in front of the brackets, the "array" name seems reasonable. So it can be something like:

local surr_arr_output = function()
  local arr_name = MiniSurround.user_input('Array name')
  return { left = arr_name .. '[', right = ']' }
end
require('mini.surround').setup({
  custom_surroundings = {
    a = { input = { '%f[%w_%.][%w_%.]+%b[]', '^.-%[().*()%]$' }, output = surr_arr_output },
  },
})

Now adding is a bit simpler (and requires no [ and ]):

• Put cursor on int in Normal mode.
• Type saiwa.
• Type Optional and <CR>.

This also has all the added benefits of a regular custom surrounding:

• sda now can delete (any) array-like surrounding. So it can convert Optional[int] back to int.
• sraa (followed by the replacement name) can replace it with another. So it can convert Optional[int] into Array[int].
• And more: sfa, sha, etc.

---

I'm thinking off something that would allow me to stay in insert mode and type:

Optional|int then press a mapping (say, <C-s>) and enter a motion for the surround.

My personal suggestion would be to get accustomed for exiting into Normal mode frequently for such text editing. Using <C-o> occasionally is also ok, of course.

[fresh2dev]

Ah, I overlooked the user prompt capability, very cool! And while I try to leave plugins as vanilla as possible (lest I venture into endless config churn), the custom surround function definitely seems worth a better understanding and investment. You've given me plenty to chew on, thanks so much!

[echasnovski]

... (lest I venture into endless config churn) ...

I completely understand that. In my experience this indeed might be a problem if configuration is done without any specific aim in sight. I.e. a problem which you want to solve and which has a verifiable way to say that it is solved.

This particular case is an example of a repetitive editing which is reasonable to make more straightforward to achieve. So my suggestion would indeed be to invest into a common surroundings. The same advice goes for 'mini.ai' and textobjects (maybe even more that for 'mini.surround').

[icoderarely]

I have a basic setup of mini.nvim from kickstart.nvim, but I'm trying to fix two things:

1. How do I show the relative path (or just the file name) in the statusline instead of the absolute path?
2. I'm using NeoTree as a file explorer. How can I disable the statusline when NeoTree is open and prevent it from showing anything in the statusline?

(Attached an image for reference)

[echasnovski]

However, when I'm actively editing a file, the statusline still shows the absolute path instead of the relative path.

This part is answered in "If it is in the active window, then it is a bit more complicated...". Define custom active content by pasting linked default code from help page and adjust to your needs. For example, set { trunc_width = 999 } here to show filename for when window is less than 999 columns wide.

[icoderarely]

content = {
  inactive = function()
    return "%#MiniStatuslineInactive#%t%="
  end,

  active = function()
    -- Modify the filename section to use relative path
    local filename = MiniStatusline.section_filename({ trunc_width = 899 })

    return MiniStatusline.combine_groups({
      { hl = "MiniStatuslineFilename", strings = { filename } },
    })
  end,
}

This gives relative path for the files in the root directory only, once I move to a directory, it shows absolute path again

[echasnovski]

This gives relative path for the files in the root directory only, once I move to a directory, it shows absolute path again

Ah, then use '%t' directly instead. So something like local filename = '%t' or directly as strings = { '%t' }.

[icoderarely]

gives just the file name, we are getting close i believe

edit: solved it using this, if there is another easier way around please let me know.
local path = vim.fn.fnamemodify(vim.fn.expand("%:p"), ":." .. vim.fn.getcwd()) and passing this as strings

thank you

[echasnovski]

If you want relative path and not file name, then use '%f' (which is what section_filename() uses for narrower widths). It is a "Path to the file in the buffer, as typed or relative to current directory." (see :h 'statusline'). On practice this indeed usually means path relative to Neovim's current working directory (see :h current-directory and :h :pwd), which can be absolute if file is not inside current working directory.

[Klvxn]

This is my current setup for mini.sessions. I didn't like that local sessions are saved in the project's directory, so I used project's name to saved session file in the global session directory. Among other configurations

-- Sessions are named based on the project name (last folder in the project path)


-- Get the last folder name from the current working directory path 
-- to use as the session name
local last_folder = function()
  -- Remove trailing slash if present
  local path = vim.fn.getcwd()
  path = path:gsub("[/\\]$", "")
  
  -- Handle both Windows and Unix-style paths
  local last_folder = path:match("[/\\]([^/\\]+)$") or path:match("^([^/\\]+)$")
  
  -- Debug info
  vim.notify("Extracting folder name from path: " .. path .. " -> " .. (last_folder or "default_session"))
  
  return last_folder or "default_session"
end

-- Setup session directory and file
local session_dir = vim.fn.stdpath('data') .. '\\session'
if not vim.loop.fs_stat(session_dir) then
  vim.loop.fs_mkdir(session_dir, 511) -- 511 = 0o777
  vim.notify("Created session directory: " .. session_dir)
end

local function get_session_file()
  local full_path = session_dir .. '\\'.. last_folder()
  return full_path
end
      

-- Initialize mini.sessions
require('mini.sessions').setup({
  -- Disable local session because we are using project-based sessions 
  -- and session names are based on the project name
  file = '',  
  
  hooks = {
    pre = {
      write = function()
        vim.notify("Pre-write hook called")
          
        -- Save all modified buffers
        vim.api.nvim_exec('silent! wall', false)

        -- Close certain windows/buffers before saving session
        for _, buf in ipairs(vim.api.nvim_list_bufs()) do
          local buftype = vim.api.nvim_buf_get_option(buf, 'buftype')
          local filetype = vim.api.nvim_buf_get_option(buf, 'filetype')
          
          -- List of filetypes/buftypes to close before saving session
          local excluded = {
            filetypes = { 'Neo-Tree', 'neo-tree', 'qf', 'help', 'gitcommit' },
            buftypes = { 'terminal', 'help' }
          }
              
          -- Close if buffer matches exclusion criteria
          if vim.tbl_contains(excluded.filetypes, filetype) or vim.tbl_contains(excluded.buftypes, buftype) then
            vim.api.nvim_buf_delete(buf, { force = true })
          end
        end
      end,
    },
  }
})

-- Add an additional command to manually create/write a session
vim.api.nvim_create_user_command('SaveSession', function()
  local session_file = get_session_file()
  vim.notify("Manually saving session to: " .. session_file)
  require('mini.sessions').write(last_folder())
end, {})

-- didn't see the need for an autocmd on VimEnter because we are using mini.starter plugin which 
-- already shows a list of previous sessions on startup

-- Auto-command to save session on exit 
vim.api.nvim_create_autocmd("ExitPre", {
  callback = function()
    vim.cmd('silent! SaveSession')
  end,
  group = vim.api.nvim_create_augroup('AutoSessions', { clear = true }),
  desc = "Automatically manage Neovim sessions"
})

[echasnovski]

Nice solution!

I'd recommend using vim.bo instead of vim.api.nvim_buf_get_option() (deprecated in favor of vim.api.nvim_get_option_value(), by the way). So local buftype = vim.api.nvim_buf_get_option(buf, 'buftype') becomes vim.bo[buf].buftype.

[HumblePresent]

This question is not really related to the plugin itself, but I am curious what terminal emulator and font combo was used to create the demo screenshots in the mini.icons README? I have used a couple different terminal emulators and a patched font or fallback font config, but never get icons to render as large as the ones in those screenshots. I realize this question is a bit off-topic so feel free to remove as you see fit.

[echasnovski]

No problem, this is not entirely off-topic :)

The main font is Input Mono (Compressed Light) and the font used for icons is a fallback NerdFontsSymbolsOnly from Nerd Fonts (as recommended).

The terminal emulator used was Ghostty, which is currently in closed beta but soon should be public. But other "modern" terminal emulators should render similarly. Make sure that icons have the space to the right so that they can "overflow" (see this).

I was curious and made a comparison with terminal emulators I have lying around:

Ghostty (with NerdFontsSymbolsOnly as fallback):

Kitty (with no explicit fallback, using the one which is built-in):

WezTerm (with no explicit fallback, using the one which is built-in; but with enabled allow_square_glyphs_to_overflow_width):

So it seems to be a matter of making sure that there is a font that supports Nerd font icons and that terminal emulator is configured to overflow special glyphs.

[HumblePresent]

Thanks for your reply. Can I ask which version of WezTerm you are using? Without an explicit fallback, and with allow_square_glyphs_to_overflow_width = "Always", I only get single cell width icons.

[echasnovski]

Thanks for your reply. Can I ask which version of WezTerm you are using? Without an explicit fallback, and with allow_square_glyphs_to_overflow_width = "Always", I only get single cell width icons.

It is pretty old: wezterm 20240203-110809-5046fc22. Are you sure there are spaces to the right of the glyph? For example, '󰢱' and '󰢱 ' will render differently.

[HumblePresent]

Ok I figured it out. I am on Arch and had the ttf-nerd-font-symbols package installed, but with the ttf-nerd-font-symbols-mono package I get the double width icons as shown in your screenshots. Not sure exactly what the difference is between those, but thanks for humoring me with this.

[name-jerry]

1. "I am currently using nvim-cmp and mini.hues. How can I highlight the current selection in cmp?"
2. "How can I prevent files from starting when opening a session with starter?"
3. "Occasionally, when opening a session with starter, a blank buffer named 'starter' appears."

[name-jerry]

Both 2 and 3 seem to be the same issue: Vim sessions preserve scratch buffers but don't save their content. Removing (manually with automation) such buffers before writing session (manually or automatically) should resolve this. I am afraid I can not help any further without actual reproduction steps of issue(s) you have.
It's done. Here's the code
···lua
local function delete_specific_buffers()
-- 遍历所有 buffer
for , i in ipairs(vim.api.nvim_list_bufs()) do
-- 获取 buffer 的 buftype 和文件名
local buftype = vim.api.nvim_get_option_value("buftype", { buf = i })
local filename = vim.api.nvim_buf_get_name(i)
-- 如果 buftype 不为空(默认值是空)或者文件名中包含 Starter_数字，删除该 buffer
if buftype ~= "" or filename == vim.fn.getcwd() or filename:match("Starter%d+") then
vim.api.nvim_buf_delete(i, { force = true })
end
end
end
require("mini.sessions").setup({
directory = vim.fn.stdpath("config") .. "sessions/",
hooks = {
-- Before successful action
pre = { read = nil, write = nil, delete = nil },
-- After successful action
post = { read = delete_specific_buffers, write = nil, delete = nil },
},
})

[echasnovski]

Nice!
Couple of small things:

• Instead of vim.api.nvim_get_option_value("buftype", { buf = i }) you can use vim.bo[i].buftype.
• Instead of filename:match("Starter%d+") I'd suggest using vim.bo[i].filetype == 'ministarter'.

[GitMurf]

Instead of vim.api.nvim_get_option_value("buftype", { buf = i }) you can use vim.bo[i].buftype.

@echasnovski I have actually wondered about this "generally" speaking from a nvim api perspective for a while now.

1. Is there a reason to use vim.bo... as opposed to the nvim api opt value method, other than the conciseness and personal preference?

2. In general is there a neovim core maintainers "stance" on whether to use methods from the vim.api.nvim... versus more native vim things like vim.bo..., vim.fn... etc?

I always assumed when there was a vim.api.nvim... method that the "neovim way" was to use that whenever possible. But now I'm not so sure that is true ;) 🤷‍♂️

I am mostly just curious for your perspective as both a plugin dev and involved as a neovim core contributor?

Thanks!

[echasnovski]

The vim.bo is a specifically built-in Lua way to get and set buffer-local options in the current Neovim session's Lua.
The nvim_get_option_value() is an API method that Neovim provides for third party programs to interact with the Neovim session. It so happens to be also available from inside current Neovim session's Lua as a method of vim.api.

Using any of the two is fine, but vim.bo is specifically designed to be more concise and be used in Lua configs and plugins.

The vim.fn is slightly different: it is a bridge to call Vimscript functions from inside current session's Lua. This involves converting Lua objects into Vimscript objects, performing operation, and convert back. This is usually negligible but should be taken into account. Usually it is fine using it (I personally prefer vim.fn.line('.') instead of vim.api.nvim_win_get_cursor(0)[1]), but there are limitations (like sometimes using inside libuv callbacks as in timer, etc.). Also, sometimes there is simply no vim.api.nvim_xxx() method for some Vimscript function (for example, dealing with virtual columns, i.e. column outside of actually present text).

So as usual, this is a case by case decision.

[GitMurf]

Using any of the two is fine, but vim.bo is specifically designed to be more concise and be used in Lua configs and plugins.

Great to know! Thanks a lot :)

[adriankarlen]

When using mini.icons and the hl-groups what is the correct way to preserve the background when for instance used in a statusline or tabline?

[echasnovski]

Default 'mini.icons' highlight only define foreground colors, so they already should preserve the background color. The issue here is that statusline, tabline, and winbar by default combine highlights with 'Normal' highlight groups. Which is why you probably see background same as in normal window. This issue is the main technical reason of why 'mini.statusline' and 'mini.tabline' don't show colored icons.

The solution here is to either define custom variations of highlight groups specifically for statusline, tabline, and winbar which would have the appropriate background. Or use Neovim 0.11 (current Nightly) with neovim/neovim#29976 merged if all you need is to combine with dedicated StatusLine, TabLine, and WinBar highlight groups. Or don't use colored icons.

[adriankarlen]

Thank you for your quick response, really nice change for my specific use case (building a tabline) coming up in 0.11. I am not running nightly, so I went and created new highlights that derived the fg color from mini.icons. For future reference in case anyone has a similar use case of mini.icons, this ended up being my resolution: adriankarlen/buffed.nvim@6e7a013

[echasnovski]

Nice solution!

Just FYI (as I'd say there is no single correct answer here), you can also get the color of highlight group attribute with the following more Neovim/API/Lua approach: string.format('#%06x', vim.api.nvim_get_hl(0, { name = group })[attr]). It might be slightly faster, but at the same time might be more error prone (if attribute doesn't exist). And it is unnecessarily more complex as nvim_get_hl() returns hex in the decimal form (presumably for performance reasons as it is how it is stored internally).

[bnhtho]

Hi @echasnovski . It possible to create new shortcut that quickly create new files in mini.pick module ?.
In old neotree plugins, i can press a key to quicky create new file. But since i switch to mini.pick it not allow me to do it again? Is possible to implement function like that by my own?

[echasnovski]

Hi @echasnovski . It possible to create new shortcut that quickly create new files in mini.pick module ?. In old neotree plugins, i can press a key to quicky create new file. But since i switch to mini.pick it not allow me to do it again? Is possible to implement function like that by my own?

Yes, it is possible to do in 'mini.pick' with custom actions.

But I'd clarify that 'mini.pick' (as the name suggests) is mostly designed to "pick one/several items and perform actions on it/them". Manipulation with file system is mostly expected to be done in 'mini.files'. It is very straightforward to quickly create file in there: 1) navigate to its parent directory; 2) press o to start new line (as in any normal buffer); 3) type file's name (with extension); 4) exit to Normal mode and press = to synchronize changes; 5) read the prompt and confirm if you agree with the change.

[dkibet]

Using mini.surround, I would love to swap how brackets handle inner edge whitespace:

• Close brackets include whitespace both on the left and right.
• Open brackets do not include inner edge whitespace.

I'm currently using custom_surroundings and it works, but I'm curious if there's a more efficient or cleaner method.

   custom_surroundings = {
        ['('] = { output = { left = '(', right = ')' } },
         ....
        ['>'] = { output = { left = '< ', right = ' >' } },
   },

Thanks for the great plugin! Any suggestions are much appreciated.

[echasnovski]

I'm currently using custom_surroundings and it works, but I'm curious if there's a more efficient or cleaner method.

A more efficient method would be to not swap and use them as is. I remember myself readjusting which key I press after finalizing this feature in 'mini.surround' (mostly because I used open and close brackets interchangeably). It is usually less troubles than it might seem initially.

But with swapping, I am afraid, explicit swapping is the only way to go. I'd also suggest adjusting "input" parts too, as they are different (you can check with sh( and sh) inside something like ( aaa )). So it would be something like this:

require('mini.surround').setup({
  custom_surroundings = {
    ['('] = { input = { '%b()', '^.().*().$' },       output = { left = '(',  right = ')' } },
    [')'] = { input = { '%b()', '^.%s*().-()%s*.$' }, output = { left = '( ', right = ' )' } },
    --- ...
  },
})

Here is a link to how they are defined by default.

[dkibet]

Thanks! I think i'll give the defaults a try

[xzbdmw]

Using mini.ai, for example:

	f(a,b,c(d))
          ^ cursor here

If I type "dia", it correctly deletes "a", while in this case, when the right ")" is in next line:

	f(a,b,c(d)
       )  ^ cursor here
           

it delete "d", can this issue be solved via config? thanks.

[echasnovski]

can this issue be solved via config? thanks.

Yes: setting config.search_method to be 'cover' will always try to find only covering textobject (instead of default 'cover_or_next' which first searches inside current line and only then inside neighborhood line). You can then select next/last textobjects with in/il/an/al keys (instead of pure i and a).

[xzbdmw]

Thank you!

[GitMurf]

echasnovski (not @ tagging you to avoid totally annoying you for a somewhat "off topic" question 😉 )

But curious as I have become more and more of a nvim config nerd and "personal plugin hacker" and learning more and more about lua and neovim in general, I find myself reaching for vim.schedule() a LOT and typically my first goto rescue attempt if something isn't quite working how I expect ;-) Curious if this is common and you find yourself doing the same? I am a javascript developer so am pretty well versed in the js event loop and async code from that perspective and I believe lua is very similar... but the amount I use vim.schedule() feels kind of "dirty" haha if you know what I mean? Just curious if I am developing bad habits or if this is a fairly common practice when it comes to neovim hacking and vim.schedule really is that magical? Thanks!

[echasnovski]

Just curious if I am developing bad habits or if this is a fairly common practice when it comes to neovim hacking and vim.schedule really is that magical?

Sometimes yes, sometimes no. vim.schedule(f) is basically "Execute f after all currently planned tasks are executed". This can be a good choice (for example, inside some autocommand callback to ensure that all other autocommands are executed before doing something) or a bad choice (for example, this will usually mean that callback will be executed after a redraw, which is a common cause of flickering if f has any visual side effects).

I think here the boring answer is the most correct: use it only when it is supposed to be used. As :h vim.schedule() says: "Useful to avoid |textlock| or other temporary restrictions.". Otherwise I'd suggest making sure that you can not achieve the same result without vim.schedule().

[name-jerry]

你好，我试着使用none-ls中的null_ls.builtins.completion.luasnip,将snipt集成到原生的补全源中,使用mini.completion的时候，我怎么获取到当前的选择的选项里面结尾是含有~(snipet的结尾都是带的)，然后对结尾含有的选项调用 require("luasnip").expand()来展开它

[echasnovski]

Translation:

Hello, I'm trying to use null_ls.builtins.completion.luasnip in none-ls to integrate snipt into the native completion source. When using mini.completion, how can I get the current selected option to contain ~ at the end (snipet always ends with ~), and then call require("luasnip").expand() to expand it?

That said, there is planned built-in snippet support in 'mini.completion' soon-ish (I hope). Meanwhile, you can try to use :h CompleteDonePre event together with :h v:completed_item info to get the item which was accepted by completion.

---

In the future, please use English to communicate here. Automated translation will do, if there is no other option.

[tvsfx]

I dynamically switch git worktrees withing one neovim instance often (using a fork of this plugin). I noticed I can easily copy files between different instances of mini.files that have different folders as their anchor, which is great :)

What does not seem to be possible, though, is to jump between bookmarks across worktrees quickly, without closing the current mini.files instance and reopening another one that's rooted in the same worktree that the bookmark was created in. It seems like marks are local to each root folder, and capitalized marks are not treated specially (unlike in vim itself). What I'd like to be able to do is use mA in one mini.files instances, and then 'A in an instance with a different anchor, and still jump to my original mark. This allows quicker file operations across folders.

Alternatively, what would be even quicker is having multiple mini.files instances in parallel, and having some sort of picker that allows switching between them (and perhaps showing off two side by side, that could be very useful for this type of operation). This is probably a more opinionated/complex change though.

[tvsfx]

This would be one way of doing this. My first idea is to create a separate mapping that opens 'mini.files' explorer in the whole project root and not in worktree's root. Or automate it with fallback to current working directory, but I'd personally prefer explicit approach.
This is also a third approach, yes. You can indeed implement persistent bookmarks either across all anchors (easy) or within anchors which are part of a single big Git repo thus sharing them only across worktree directories (hard).

Yeah, I already have separate keybinds to open the project root instead of file's parent directory. This is not yet sufficient, because what I consider the best folder to jump to when MiniFiles.reset is called does not necessarily coincide with the scope in which I want bookmarks to be remembered. Since I use tmux to track sessions and use one nvim instance for multiple git worktrees, I'll probably go ahead and tweak your solution above to find the current tmux session root (if any) and store/restore bookmarks for all mini.files instances that belong to the same tmux session. Then my keybind just needs to open a mini.files instance that has a branch pointing to the current file, that has the git folder as its anchor, and that uses the tmux session path (usually the parent folder of the git folder) for the bookmarks.

Another suggestion would be to detect and autocreate bookmarks for all (or the ones that you usually want) worktree directories.

This could be a nice complimentary approach :) although parsing the output of something like git worktree list is probably a bit of work, and is not much faster than just navigating up from the root and back down into another folder.

The 'mini.files' assumption is indeed that different anchors represent different projects (and current working directories).

Given that this is true, I find it strange that mini.files does not provide an option out of the box to open an instance that has the current file as the end of the branch, and the cwd as the anchor; usually the file's parent directory is not the project root. This is what makes most sense to me.

All in all, I don't think adjusting 'mini.files' design/capabilities to fit the "allow editing file in the middle of file system manipulation" is a reasonable idea. It looks more like adjusting user workflow and/or config type of situation.

That's entirely fair :) thanks a lot for your advice and comments!

[echasnovski]

Given that this is true, I find it strange that mini.files does not provide an option out of the box to open an instance that has the current file as the end of the branch, and the cwd as the anchor; usually the file's parent directory is not the project root. This is what makes most sense to me.

It is mostly because I don't think there is both clean and robust solution for any combination of file and cwd (as passed file path can be not inside cwd). Plus it introduces a separate abstraction (cwd) when opening a file, which needs a lot of justification. Right now, there is a single anchor abstraction which is used as id when storing history and during reset(). Instead there is a @ and reveal_cwd() for users to either explicitly press or set up to show automatically.

[tvsfx]

It is mostly because I don't think there is both clean and robust solution for any combination of file and cwd (as passed file path can be not inside cwd). Plus it introduces a separate abstraction (cwd) when opening a file, which needs a lot of justification. Right now, there is a single anchor abstraction which is used as id when storing history and during reset(). Instead there is a @ and reveal_cwd() for users to either explicitly press or set up to show automatically.

I dont see the cwd as a separate abstraction necessarily; I'd just have an optional anchor argument to MiniFiles.open, which the user can pass whatever they want into, including the current value of the cwd. If the file's path is not under this anchor, you indeed have to make an arbitrary choice on what to do, which -I assume- is why you don't like this. Out of the three options (show file, show anchor, show shared root folder with branch to file), the first or third options probably make the most sense. In a way, what I'm suggesting here is the dual of reveal_cwd(); instead of revealing the cwd from the file, this would reveal the file from the cwd (or anchor).

[echasnovski]

I dont see the cwd as a separate abstraction necessarily; I'd just have an optional anchor argument to MiniFiles.open, which the user can pass whatever they want into, including the current value of the cwd. If the file's path is not under this anchor, you indeed have to make an arbitrary choice on what to do, which -I assume- is why you don't like this.

There is no file, no anchor, no cwd arguments. There is a single path which is designed for directory path. This path will be used as id when storing history and the one shown after reset(). As "show current file in its parent directory" is a common use case, path argument was extended to allow file path. As both storing history and reset() require directory path, the "anchor" abstraction was introduced: same as path for directory path and file's parent for file path.

Any other changes to what branch is shown after open() are expected to be tweaked by the user with provided helpers and events. No new changes to the design are planned.

[tvsfx]

There is no file, no anchor, no cwd arguments.

I forgot that the only argument is path and not file, my bad. Anyway, I was just trying to describe an alternative API.

Any other changes to what branch is shown after open() are expected to be tweaked by the user with provided helpers and events. No new changes to the design are planned.

I'm thankful for these helpers; they should allow me to construct the API that I described :)

[harg]

Hello;

I can't figure how to display function signature in mini.completion menu for Typescript LS.
It works well in go :

But not with typescript code :

Here is my config :

-- ...
  {
    "echasnovski/mini.completion",
    -- {{{
    version = false,
    event = "VeryLazy",
    keys = {
      {
        "<tab>",
        [[pumvisible() ? "\<c-n>" : "\<tab>"]],
        mode = "i",
        expr = true,
      },
      {
        "<s-tab>",
        [[pumvisible() ? "\<c-p>" : "\<s-tab>"]],
        mode = "i",
        expr = true,
      },
    },
    config = function()
      require("mini.completion").setup {
        window = {
          info = { border = "single" },
          signature = { border = "single" },
        },
      }
    end,
    -- }}}
  },
  {
    "neovim/nvim-lspconfig",
    -- {{{
    event = { "BufReadPre", "BufNewFile" },
    config = function()
      -- import lspconfig plugin
      local lspconfig = require "lspconfig"

      local keymap = vim.keymap -- for conciseness

      -- Disable semantic tokens (too slow)
      lspconfig.util.default_config = vim.tbl_extend("force", lspconfig.util.default_config, {
        on_attach = function(client)
          client.server_capabilities.semanticTokensProvider = nil
        end,
      })

      vim.api.nvim_create_autocmd("LspAttach", {
        group = vim.api.nvim_create_augroup("UserLspConfig", {}),
        callback = function(ev)
          -- Buffer local mappings.
          -- See `:help vim.lsp.*` for documentation on any of the below functions
          local opts = { buffer = ev.buf, silent = true }

          -- set keybinds

          opts.desc = "See available code actions"
          keymap.set({ "n", "v" }, "<leader>a", vim.lsp.buf.code_action, opts) -- see available code actions, in visual mode will apply to selection

          opts.desc = "Rename symbol"
          keymap.set("n", "<leader>r", vim.lsp.buf.rename, opts)

          opts.desc = "Go to previous diagnostic"
          keymap.set("n", "(d", vim.diagnostic.goto_prev, opts) -- jump to previous diagnostic in buffer

          opts.desc = "Go to next diagnostic"
          keymap.set("n", ")d", vim.diagnostic.goto_next, opts) -- jump to next diagnostic in buffer

          opts.desc = "Show documentation for what is under cursor"
          keymap.set("n", "<leader>k", vim.lsp.buf.hover, opts) -- show documentation for what is under cursor
        end,
      })

      -- Change the Diagnostic symbols in the sign column (gutter)
      -- local signs = { Error = "●", Warn = "●", Hint = "●", Info = "●" }
      -- for type, icon in pairs(signs) do
      --   local hl = "DiagnosticSign" .. type
      --   vim.fn.sign_define(hl, { text = icon, texthl = hl, numhl = "" })
      -- end

      -- Highlight line number instead of having icons in sign column
      for _, diag in ipairs { "Error", "Warn", "Info", "Hint" } do
        vim.fn.sign_define("DiagnosticSign" .. diag, {
          text = "",
          texthl = "DiagnosticSign" .. diag,
          linehl = "",
          numhl = "DiagnosticSign" .. diag,
        })
      end

      vim.diagnostic.config {
        virtual_text = {
          prefix = " ●",
        },
      }

      -- local lspservers =  {"ts_ls", "html", "cssls", "tailwindcss", "emmet_ls", "gopls", "denols"}
      local lspservers = { "ts_ls", "gopls" }
      for i, v in ipairs(lspservers) do
        lspconfig[v].setup {}
      end
    end,
    -- }}}
  },

[echasnovski]

If you are talking about the text at the right side of completion popup, then it is completely decided by the LSP server response. Currently it is a detail value of each CompletionItem which is meant as "A human-readable string with additional information about this item, like type or symbol information.". LSP server is allowed to not pass it, and this is apparently what happens with Typescript. This will be addressed in #1258.

[harg]

Happy new year 2025 @echasnovski !! thank you again for your work on mini.nvim, you've made my Neovim journey a lot more fun! :)

I can't manage to have https://github.com/kristijanhusak/vim-dadbod-completion working with mini.completion, is it possible to configure them together?

[echasnovski]

Hi! Likewise!

I can't manage to have https://github.com/kristijanhusak/vim-dadbod-completion working with mini.completion, is it possible to configure them together?

The 'mini.completion' supports only two "sources" (which are applied consecutively): LSP and fallback. So there can be only two ways of achieving that:

• Turn 'vim-dadbod-completion' into a separate LSP server.
• Use the built-in omnifunc as a fallback. The first approximation of this might be something like this:

  autocmd FileType sql lua vim.bo.omnifunc = 'vim_dadbod_completion#omni'; vim.b.minicompletion_config = { fallback_action = '<C-x><C-o>' }

[harg]

Thank you! I made it work. Omnifunc was overwritten each time an SQL buffer was saved with my mini.completion configuration :

        lsp_completion = {
          source_func = "omnifunc", -- <- set it to completefunc
          auto_setup = true,
        },

ended up with this autocmd in my plugin init function :

      vim.api.nvim_create_autocmd({ "FileType" }, {
        pattern = { "sql", "mysql", "plsql" },
        callback = function()
          vim.bo.omnifunc = "vim_dadbod_completion#omni"
          vim.b.minicompletion_config = { fallback_action = "<C-x><C-o>" }
        end

[echasnovski]

With surprisingly heavy heart I am going to close this discussion. Exactly three years after it was created. Two main reasons for this decision are that it became overwhelmingly big and it is not as easily searchable as separate questions (which can have dedicated module labels attached to them).

Now the only preferred way to ask a question about configuration and usage of 'mini.nvim' is to create a separate "Q&A" discussion.

Thank you all for three years of curiosity about 'mini.nvim'!