Skip to content
This repository has been archived by the owner on Dec 11, 2023. It is now read-only.

Windows width changes when navigating code action menu #52

Open
jcowgar opened this issue May 2, 2022 · 5 comments · May be fixed by #69
Open

Windows width changes when navigating code action menu #52

jcowgar opened this issue May 2, 2022 · 5 comments · May be fixed by #69

Comments

@jcowgar
Copy link

jcowgar commented May 2, 2022

The windows change in width and many times word wrap when moving from option to option in the menu. I introduced an error in my NeoVim config to show this problem. I've attached two screen shots.

It seems to take the width of the diff window.

To replicate, add unpack() with no parameters in your NeoVim .lua config somewhere and call CodeActionMenu with your cursor on unpack().
one
two

@kotatsuyaki
Copy link

To add to this issue, this seriously hurts usability. Since the width changes while navigating the menu by pressing up and down, options with long text occasionally wraps and unwraps, causing all the options below to jump up and down. The width of the popup should be kept no smaller than the longest line among the options.

@MangoIV
Copy link

MangoIV commented May 29, 2023

does anybody have solution for this? I'm really bad with lua

@SirWrexes
Copy link

Recently started using this in combination with coc-code-action-menu and I'm sad there doesn't seem to be a fix yet.
From what I gather, the overall width of the menu depends on the width of the code window, but sometimes there's no code window at all. The width should be determined based on the longest action's text.
image
image
image
This is quite unpractical.

Gelio added a commit to Gelio/nvim-code-action-menu that referenced this issue Nov 28, 2023
Context: The order of stacked windows is: menu, details, diff. The
stacking window width was set sequentially for each window and relied
only on the buffer content of the last window and the current window.
This meant that when the diff window content was wider than the details
window content, the diff window resized all windows in its stack (menu,
details) to match the width of the diff window.

Problem: This logic ignores the fact that the menu window could be wider
than the details window. In such a situation, when the details window
was being opened, it adjusted its width to match the width of the wider
menu window. However, since the diff window only looked at buffer
contents of the details window, and not at the actual window width of
the details window, it assumed that the diff window is the widest one,
and set the width of the menu window and the details window to match the
diff window. This makes the menu window narrower than its content.

Solution: Change the `StackingWindow:after_opened()` window resize logic
to look at the *actual* window width, rather than the buffer content
width. When `after_opened()` runs for the diff window, it correctly can
identify that the details window was resized due to the menu window
being wider, and correctly makes all windows' width be `max(diff window,
previous windows)`.

Fixes weilbith#52
@Gelio
Copy link
Contributor

Gelio commented Nov 28, 2023

I believe I fixed it in #69

Now it's just a matter of keeping our fingers crossed that @weilbith is still around and maintains this repository 😅

@weilbith
Copy link
Owner

Sorry, I struggle a lot with this plugin. It is in a prototype state and any rewrite I did has been discarded by myself. Was unlucky to share this on Reddit. I feel really sorry about this. Thinking about archiving it.

Anyhow, in regards of this ticket, could anybody try out the PR and confirm that it solves the problem for him? Then I'm happy to just merge it.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants