mini.map is overlapping the winbar

[alycklama]

Contributing guidelines

• [X] I have read CONTRIBUTING.md
• [X] I have read CODE_OF_CONDUCT.md
• [X] I have updated 'mini.nvim' to latest version

Module(s)

mini.map

Description

The map is always overlapping with the winbar. In this case, I have a configured the winbar with Lualine.

Neovim version

0.10.0

Steps to reproduce

1. Set the winbar (e.g. set winbar=%=%m\ %f)
2. Toggle the map to make it appear

Expected behavior

I would have hoped the floating window to take the size of the winbar into consideration.

Actual behavior

It's currently overlapping, making it very hard to see any right-aligned content in the winbar.

[echasnovski]

Thanks for the suggestion!

Taking into account only tabline, statusline, and cmdline was a deliberate decision. The problem here is two-fold:

• There can be several winbars across the height of the map floating window, as windows can be split. Thus making "map should not overlap winbar" impossible to achieve for 100% of windows.
• Accounting only for the winbar in the top right corner is not trivial as is needs a parsing of the whole window layout to identify which window affects top right corner and whether it has winbar.

One possible solution would be to specially account for the case when there is only one window with a winbar. What I don't like about it is that map will not behave similarly after any split: it can increase height and still cover some winbar.

I'll think about it, but it doesn't look like there is a robust solution to this problem (apart from not accounting for winbar at all).

[alycklama]

Thanks for your reply! I was thinking about the relationship between the mini map and the split windows, and I had an idea I wanted to share with you.

What if the mini map was associated with the currently active split window? This would create a 1-on-1 relationship between each split window and its own mini map.

When the mini map is toggled on for a specific split window, it could be displayed within the dimensions of that split, excluding the winbar. If the user moves to a different split window, the mini map could be hidden or shown based on the state of the mini map for that particular split.

This approach would require maintaining separate mini map instances for each split window. Instead of having a single global mini map, you would need to keep track of the state (visible or hidden) of n mini maps, where n is the number of active split windows.

By implementing this 1-on-1 relationship, the mini map would become specific to each split window, allowing independent control over its visibility and ensuring that it is displayed only within the bounds of its associated split. I understand that this might require some changes to the current implementation, but I thought it could be an interesting idea to consider.

Please let me know your thoughts on this suggestion, and feel free to disregard it if it doesn't align with your vision for the project.

[echasnovski]

What if the mini map was associated with the currently active split window? This would create a 1-on-1 relationship between each split window and its own mini map.

Thanks for the suggestion!

I actively thought about this approach during development of 'mini.map'. I believe the current design of one-to-one relationship of map window and tabpage was chosen mostly because it is simpler. Not only it needs more nested data structures to keep track of map buffers, but overall behavior would need to react to more events (like WinResized, etc.).

As 'mini.map' is already not a small module, I don't think refactoring to have map per window is worth it.

[alycklama]

As 'mini.map' is already not a small module, I don't think refactoring to have map per window is worth it.

I can fully imagine! Thanks for your elaborate explanation, though!

I'll close this feature request then, because you made a clear and conscious decision to not support multiple split windows.

Thanks again, and amazing work you're doing with all the mini plugins! 😄

[echasnovski]

Yeah, the best compromise seems to account only for a single window in a tabpage, but it indeed doesn't look good when map's height depends on whether there are splits or not. Thanks for understanding!