Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ResizePane() resizes first/the most left pane #3046

Open
dustdfg opened this issue Nov 27, 2023 · 3 comments
Open

ResizePane() resizes first/the most left pane #3046

dustdfg opened this issue Nov 27, 2023 · 3 comments

Comments

@dustdfg
Copy link
Contributor

dustdfg commented Nov 27, 2023

Description of the problem or steps to reproduce

I want a sidebar (from the right side) so what I do:

  1. Create buffer
  2. Create split index from the buffer
  3. Use ResizePane function on freshly created pane of sidebar
local sidebar_buf = buffer.NewBuffer("", "sidebar")

-- true here means to create it from right
sidebar =  bp:VSplitIndex(sidebar_buf, true)

sidebar:ResizePane(35)

What I expect:

Sidebar shrinks to size 35.

What I get:

The opened file that is on the left side shrinks to size 35

After getting something wrong I decided to try another thing. I decided to create sidebar on the left side and see what I will get. When I created the sidebar on the left side and tried to change it is size, I saw that this time it worked as expected. The sidebar shrink but I think it is only because it was on the left side and the function has a bug. It doesn't actually resize pane from which it was called. It just resizes the most left pane

Specifications

Commit hash: Version: 2.0.11 (it doesn't show commit hash)
OS: Debian 12
Terminal: foot

@JoeKar
Copy link
Collaborator

JoeKar commented Nov 28, 2023

The problem is from my point of view within splits.go#L143 respective splits.go#L164, because they don't really respect if the last or a previous child will be resized and depending on this the action done c1 and c2 need to be exchanged.

@dustdfg
Copy link
Contributor Author

dustdfg commented Nov 29, 2023

Bug is also present in v2.0.13 68d88b5

@JoeKar
Copy link
Collaborator

JoeKar commented Nov 29, 2023

Yep, I know...I reproduced it with the current master.
I think we've to add a bit more logic into the above two functions to get it running as expected. But even then, don't expect it to be merged quite soon, because the project owner currently hasn't the time to take care and we volunteers don't have the rights. ;)

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

No branches or pull requests

2 participants