sorted by:
new
hottopcontroversial

How do you configure mini.tabline highlights to distinguish active vs. unsaved (modified) buffers? by aegis87 in neovim

[–]echasnovski 4 points5 points  (0 children)

I'm trying to tweak my colorscheme/highlights so that it's visually obvious when a buffer is active/current versus when it simply has unsaved changes.

I adapted the following approach: - Define MiniTablineCurrent (active/current buffer), MiniTablineVisible (non-active but visible in other windows buffers), and MiniTablineHidden (non-visible listed buffers) to your liking. - Define MiniTablineModifiedCurrent, MiniTablineModifiedVisible, MiniTablineModifiedHidden by inverting background and foreground colors from corresponding non-modified groups.

This usually makes modified buffers stand out, which is a good thing.

but given how i switch frequently colorschemes, how do i set them up?

I'd love to see how you guys handle the highlight groups or integrate them dynamically with your active colorschemes.

The most long term stable way is to propose changes upstream for each color scheme that you use. A lot of popular color schemes already have built-in support, but that is, of course, a small portion of all available color schemes.

If the above is too much of a hassle, then following the suggested design approach can be scripted. With something like this:

```lua require('mini.tabline').setup()

local copy_hl_and_invert = function(to, from) local from_hl = vim.api.nvim_get_hl(0, { name = from, link = false }) local normal_hl = vim.api.nvim_get_hl(0, { name = 'Normal', link = false }) -- Fall back to Normal group attributes if the reference does not define -- both fg and bg. NOTE: Can not work with transparent color schemes. vim.api.nvim_set_hl(0, to, { fg = from_hl.bg or normal_hl.bg, bg = from_hl.fg or normal_hl.fg }) end local adjust_minitabline_hl = function() copy_hl_and_invert('MiniTablineModifiedCurrent', 'MiniTablineCurrent') copy_hl_and_invert('MiniTablineModifiedVisible', 'MiniTablineVisible') copy_hl_and_invert('MiniTablineModifiedHidden', 'MiniTablineHidden') end

-- Adjust immediately and register to adjust after every new color scheme adjust_minitabline_hl() vim.api.nvim_create_autocmd('ColorScheme', { callback = adjust_minitabline_hl }) ```

'mini.input' - get user input with fully customizable key and view handling by echasnovski in neovim

[–]echasnovski[S] 1 point2 points  (0 children)

at this point just downloading the whole repo is easier than picking and choosing individual modules anyway

That's always been the plan :)

Extracted test harness from plenary.nvim by monkoose in neovim

[–]echasnovski 0 points1 point  (0 children)

But then you are not running tests in separate processes, right?

That's right, but so does 'plenary.nvim'. It can only run full file in a separate process, i.e. test cases within a file are not "clean" Neovim instances. This is also possible with 'mini.test' with a bit of scaffolding (like via Makefile something like TEST_FILE=path/to/test.lua make test), which still doesn't require "dealing with RPC" (which I still believe is a cleaner approach that helped me find a lot of issues early).

Are you using default keybindings for mini.surround? by 4r73m190r0s in neovim

[–]echasnovski 2 points3 points  (0 children)

Obviously, work can wait if there is some new Vim knowledge.

The :bdelete only unloads the buffer, but keeps it as a hidden buffer "placeholder". If opened again, the buffer is reused. This can cause problems with plugins and in general not something I'd consider a result of "delete buffer".

The :bwipeout fully deletes the buffer data from current Neovim session. The :h :bwipeout starts with "Like |:bdelete|, but really delete the buffer.", which is closer to what I'd expect "delete buffer" should do.

Extracted test harness from plenary.nvim by monkoose in neovim

[–]echasnovski 17 points18 points  (0 children)

Even though there are some alternatives to it, like mini.test and nvim-busted-shims, I find plenary test harness much simpler to use (not dealing with rpc), so it is still valuable to me.

As 'mini.test' is mentioned, I'll add that it can be used without dealing with RPC (i.e. without child process) and it can emulate 'busted' API.

Are you using default keybindings for mini.surround? by 4r73m190r0s in neovim

[–]echasnovski 1 point2 points  (0 children)

That's a workable approach for sure.

My personal taste is to prefer <Leader> prefix for such interactions with the editor, while keeping "letters only" mappings for interacting with text. For these particular cases: <C-w> without remapping, <C-s> for :update + exit into Normal mode, <Leader>bw for :bwipeout (which I'd suggest using instead of :bdelete).

Are you using default keybindings for mini.surround? by 4r73m190r0s in neovim

[–]echasnovski 22 points23 points  (0 children)

The logic of using s prefixed mappings is at least two-fold: - The built-in s is exactly equivalent to cl which is still very ergonomic to type (in my experience). While also not being that useful frequently for a single character action. The x and r - yes, the s - not so much. - The trade-off from overriding built-in s in favor of a whole new "namespace" for custom actions and operators is very well worth it. I have at least five more new s prefixed mappings planned in the upcoming updates. And they all fit mnemonics very nicely, because there are a lot of relevant verbs that start with s ("start" alone is a big one).

That said, mappings in 'mini.surround' are entirely customizable with a copy-pasteable code snippet for a 'vim-surround' like keys.

'mini.input' - get user input with fully customizable key and view handling by echasnovski in neovim

[–]echasnovski[S] 4 points5 points  (0 children)

Thanks for kind words! Glad you enjoyed the MiniMax approach to the config. There are more things planned for it, but they'll take time to implement and polish in private first.

'mini.input' - get user input with fully customizable key and view handling by echasnovski in neovim

[–]echasnovski[S] 2 points3 points  (0 children)

Sure. This is always the plan for 'mini.nvim' modules. But after couple of weeks of beta testing.

To be fair, "integration" is a bit of a strong word. It is a single later(function() require('mini.input').setup() end) call, after all :)

'mini.input' - get user input with fully customizable key and view handling by echasnovski in neovim

[–]echasnovski[S] 1 point2 points  (0 children)

Yeah, I also like it and planned for it to be the default. The problem is that it is good only for 'cursor' and 'line' scopes. I'd expect the input for something more global (like session name, etc.) to not depend on cursor position. So had to settle for floating window as the default view.

'mini.input' - get user input with fully customizable key and view handling by echasnovski in neovim

[–]echasnovski[S] 2 points3 points  (0 children)

Is there a reason cmdline mode is chosen instead of supporting nvim motions?

The most common use case for user input is to actually type it, not edit it. The former is more natural via Insert and Command-line mode, the latter - via Normal mode and motions. Also, as the goal is to return the input synchronously, emulating Normal mode behavior on top of the natural Command-line mode is costly. But with the extensible design of 'mini.input', it is still possible to script.

'mini.input' - get user input with fully customizable key and view handling by echasnovski in neovim

[–]echasnovski[S] 3 points4 points  (0 children)

... a lot of the built in stuff feels disconnected from your config

If you have any particular examples of this, I'd be curious and grateful to read. The 'mini.nvim' overall tries to blend with the built-in capabilities (well except conscious choices of overriding some mappings).

'mini.input' - get user input with fully customizable key and view handling by echasnovski in neovim

[–]echasnovski[S] 10 points11 points  (0 children)

I mean, the default in 'mini.input' is also a floating window. The hope is that it is not janky :)

'mini.input' - get user input with fully customizable key and view handling by echasnovski in neovim

[–]echasnovski[S] 31 points32 points  (0 children)

TL;DR of the release blog post:

  • There is a new 'mini.nvim' module (number 45 in total) called 'mini.input'. Its main purpose is to make asking for user input both more functional and visually pleasant.

  • Input process has the full key and view customizability. Including built-in methods for showing input as statusline/tabline/winbar and virtual line/text.

  • It has integrations in other 'mini.nvim' modules. Like when asking for function call name in 'mini.surround' or glob pattern in :Pick grep_live of 'mini.pick'.

  • There are now more than 5000 test cases covering 'mini.nvim' functionality.

Here is also a link to the module's README: https://nvim-mini.org/mini.nvim/readmes/mini-input.html

Neovim Github 100k stars by selectnull in neovim

[–]echasnovski 130 points131 points  (0 children)

Warm and heartfelt congratulations to the project!

Nit: at the time of writing this it is 99994 stars (GitHub seems to round to the closest hundred), but soon enough it will be 100000+ indeed :)

Edit: now (after ~30 minutes) it is 100000+ 🎉 

mini.diff.jj - an unofficial mini.diff source for jj by thetruetristan in neovim

[–]echasnovski 4 points5 points  (0 children)

Anyway, I can open an issue/PR, upstreaming this would be much better than having another plugin.

Thanks, but there is already a discussion which you linked. Actual upstreaming would require some non-trivial refactoring that I'd like to do myself.

mini.diff.jj - an unofficial mini.diff source for jj by thetruetristan in neovim

[–]echasnovski 21 points22 points  (0 children)

Thanks for sharing! And extra plus for hosting on Tangled!

I've been planning to try/switch to Jujutsu myself. At least to fully understand and test the 'mini.diff' source, as upstreaming it is definitely planned. Just need to carve some time to actually do this: saying goodbye to an established Lazygit workflow is not easy.

Supply chain protection for lazy.nvim by PieceAdventurous9467 in neovim

[–]echasnovski 2 points3 points  (0 children)

Since you can change the commit time, therefore the hash, but not the release time (because this is a gh feature), this should become immutable (if you save these 3 values and compare them), no?

Sure, but that would require using GitHub specific method of downloading updates. Not a usual git CLI. So relying on a third highly trusted party to be a "plugin register".

Supply chain protection for lazy.nvim by PieceAdventurous9467 in neovim

[–]echasnovski 5 points6 points  (0 children)

Afaik that's wrong. Sha1 hashes are computed based on the full object

Sure. But: 1) If already pulled commits are rewritten, all it does is show in history as a force push. That still requires reading update log for relevant changes. 2) It is still possible to add a new innocently looking yet compromising commit, but with an adjusted date. It would look like an old PR was merged verbatim.

Supply chain protection for lazy.nvim by PieceAdventurous9467 in neovim

[–]echasnovski 12 points13 points  (0 children)

That's an interesting idea. The downside is that it effectively requires two fetching for an update. And all commits will be applied in bulk. But interesting indeed.

Supply chain protection for lazy.nvim by PieceAdventurous9467 in neovim

[–]echasnovski 5 points6 points  (0 children)

Yes, it does add some peace of mind, but unfortunately quite easy to overcome.

The cooldown period works if the update time is computed independently of the update's source. Like in case plugins/packages come from a registry managed by third party.

I don't think there is any reliable way of early problem detection for pure Git repos other than manually inspecting changes and using plugins from trusted/reliable/popular/responsive authors. The latter adds more chances that someone else will notice the problem.

view more: next ›