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.

Sign up for GitHub

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

Jump to bottom

quickfix window grows when opening results in vsplit or tab #150

Closed
haolian9 opened this issue Jan 16, 2015 · 9 comments
Closed

quickfix window grows when opening results in vsplit or tab #150

haolian9 opened this issue Jan 16, 2015 · 9 comments
Assignees
@ches
Labels
enhancement

Comments

@haolian9
Copy link

After :Ack Controller, I get
1,
in quickfix window use v to open a search result with vertical split window, it works well.
But if the vertical window more than 2, every time use v, the quickfix window increase, like
2 and
3 and
4
@haolian9
Copy link
Author

Maybe I forget to write out my question: why quickfix window incresed when vertical split window more than 2 ?

@ches ches self-assigned this Feb 12, 2015
ches added a commit that referenced this issue Feb 20, 2015
@ches
Preserve list window height on vertical mappings
3c4de07 
Quick fix for #150

Removes the ability to provide custom mappings for 'v' and 'gv' for now,
this mapping approach is pretty insane and ought to be refactored before
this is merged.
@ches
Copy link
Collaborator

ches commented Feb 20, 2015

You're right, and this is annoying.

I've fixed it on the preserve-list-size branch—just for sake of a quick fix I've removed the ability to configure the v and gv list window mappings, so this is going to need a bit more work before I can merge it to master, but if you don't care about controlling exactly what those mappings do then please give it a try!

The way the mappings configuration is handled is pretty silly really, I'm going to redo that completely I think but I'll need to take some steps for backwards compatibility or do a major version bump, so it'll be a little longer before I can finish this.

@ches
Copy link
Collaborator

ches commented Feb 20, 2015

I'll of course leave this issue open and update it when the fix gets merged to mainline.

ches added a commit that referenced this issue Feb 20, 2015
@ches
Preserve list window height on vertical mappings
f04a8a9 
Quick fix for #150

Removes the ability to provide custom mappings for 'v' and 'gv' for now,
this mapping approach is pretty insane and ought to be refactored before
this is merged.
@ches ches mentioned this issue Jun 6, 2015
Open
@ches ches mentioned this issue Jan 6, 2016
Open
@QMonkey
Copy link

QMonkey commented Feb 29, 2016

Same problem in tab window.

@ches ches mentioned this issue Jun 16, 2016
Open
@ches ches changed the title open a search result with v in quickfix window quickfix window grows when opening results in vsplit or tab Jun 16, 2016
@Nebuchadrezzar
Copy link

Any chance this is going to enter master soon?

@eldemcan
Copy link

Looking forward for this fix as well. It is quite annoying in terms of usability. Is there any workaround for that ?

@max-ch9i
Copy link

It'd be nice to have the fix in master.

@ches ches mentioned this issue Apr 3, 2018
Closed
matt1003 added a commit to matt1003/quickr-preview.vim that referenced this issue May 16, 2018
@matt1003
fix bug: qf/loc window grows in size when closing preview window
70f64a2 
This seems to be a common bug:

mileszs/ack.vim#150
vim-syntastic/syntastic#1489

For me, the issue occurs when I have NERDTree open; each time I close
the preview window, the qf/loc window grows to fill the space that was
previously filled by the preview window. This will continue to occur on
each preview window close, until the qf/loc window takes up the entire
screen.

The fix introduced by this patch is to force the qf/loc window back to
its original size each time the preview window closed. This fix is a bit
hacky, but it seems to work well.
matt1003 added a commit to matt1003/quickr-preview.vim that referenced this issue May 16, 2018
@matt1003
fix bug: qf/loc window grows in size when closing preview window
69f6794 
This seems to be a common bug:

mileszs/ack.vim#150
vim-syntastic/syntastic#1489

For me, the issue occurs when I have NERDTree open; each time I close
the preview window, the qf/loc window grows to fill the space that was
previously filled by the preview window. This will continue to occur on
each preview window close, until the qf/loc window takes up the entire
screen.

The fix introduced by this patch is to force the qf/loc window back to
its original size each time the preview window closed. This fix is a bit
hacky, but it seems to work well.
matt1003 added a commit to matt1003/quickr-preview.vim that referenced this issue May 17, 2018
@matt1003
fix bug: qf/loc window grows in size when closing preview window
0fd0142 
This seems to be a common bug:

mileszs/ack.vim#150
vim-syntastic/syntastic#1489

For me, the issue occurs when I have NERDTree open; each time I close
the preview window, the qf/loc window grows to fill the space that was
previously filled by the preview window. This will continue to occur on
each preview window close, until the qf/loc window takes up the entire
screen.

The fix introduced by this patch is to force the qf/loc window back to
its original size each time the preview window closed. This fix is a bit
hacky, but it seems to work well.
matt1003 added a commit to matt1003/quickr-preview.vim that referenced this issue May 22, 2018
@matt1003
fix bug: qf/loc window grows in size when closing preview window
3e27575 
This seems to be a common bug:

mileszs/ack.vim#150
vim-syntastic/syntastic#1489

For me, the issue occurs when I have NERDTree open; each time I close
the preview window, the qf/loc window grows to fill the space that was
previously filled by the preview window. This will continue to occur on
each preview window close, until the qf/loc window takes up the entire
screen.

The fix introduced by this patch is to force the qf/loc window back to
its original size each time the preview window closed. This fix is a bit
hacky, but it seems to work well.
@matt1003 matt1003 mentioned this issue May 22, 2018
Closed
@Integralist
Copy link

👋🏻 I see a bunch of issues raised that seem to just be gathering tumbleweed, even though they appear to be issues worth fixing. I don't believe the project is unmaintained so is there anything users can do to help the maintainer get these issues resolved?

I imagine opening PRs would be one approach and contributing fixes, but I can see (just as an example) another issue #142 that I have where someone actually opened a PR to fix it, but the PR has sat open for the last 7 years 😬. Maybe that happened because the maintainer expects those types of fixes to be incorporated manually by a user 🤔

Maintaining free software without getting paid for it is hard (especially when you've got a life to live), so it would be nice to get a clearer understanding of what's expected/needed from the maintainer on this project. ❤️

@haolian9
Copy link
Author

even after 7 years, I still did not learn vimscript so that i can send a PR; and seems this issue nobody cares, I am closing this issue from my side

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ches ches

Labels
enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@ches @Integralist @Nebuchadrezzar @max-ch9i @eldemcan @QMonkey @haolian9