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

Option to not auto-open first match #59

Closed
pyrat opened this issue Dec 10, 2012 · 21 comments
Closed

Option to not auto-open first match #59

pyrat opened this issue Dec 10, 2012 · 21 comments

Comments

@pyrat
Copy link

pyrat commented Dec 10, 2012

Hi there,

Is it possible to configure Ack.vim so that it does not auto-open the first file which matches the search term?

Cheers,
Alastair

@mislav
Copy link

mislav commented Jan 26, 2013

Use it like :Ack!

The bang character added to most commands will prevent the initial term to be jumped to. See #31

@pyrat
Copy link
Author

pyrat commented Jan 28, 2013

Excellent, thanks for this tip, exactly what I needed, thanks.

On 26 January 2013 19:28, Mislav Marohnić notifications@github.com wrote:

Use it like :Ack!

The bang character added to most commands will prevent the initial term to
be jumped to.


Reply to this email directly or view it on GitHubhttps://github.com//issues/59#issuecomment-12739649.

@megalithic
Copy link

@mislav big ups for that; was driving me nuts!

@lkraav
Copy link

lkraav commented Jul 1, 2013

+2!

@shanefulmer
Copy link

Thanks - was also driving me nuts!

@pyrat
Copy link
Author

pyrat commented Aug 23, 2013

Would be sweet if we could make this the default?

On 23 August 2013 01:30, shanefulmer notifications@github.com wrote:

Thanks - was also driving me nuts!


Reply to this email directly or view it on GitHubhttps://github.com//issues/59#issuecomment-23134033
.

@mislav
Copy link

mislav commented Aug 23, 2013

Would be sweet if we could make this the default?

Probably won’t happen. You should make a custom command/mapping for yourself to
use the bang by default.

@pyrat
Copy link
Author

pyrat commented Aug 23, 2013

I looked into this previously, but couldnt find a way to do it due to the
implementation of the bang. Anyone have any tips on how to achieve this?

On 23 August 2013 11:55, Mislav Marohnić notifications@github.com wrote:

Would be sweet if we could make this the default?

Probably won’t happen. You should make a custom command/mapping for
yourself to
use the bang by default.


Reply to this email directly or view it on GitHubhttps://github.com//issues/59#issuecomment-23154048
.

@ketiko
Copy link

ketiko commented Sep 23, 2013

👍 I started using ack from bash instead because of this. Awesome to know I can switch back now.

@Dieterbe
Copy link

Dieterbe commented Nov 8, 2013

+1 to make this configurable

mmrwoods pushed a commit to mmrwoods/dotfiles that referenced this issue Jan 16, 2014
Don't auto-open first match in current buffer

See mileszs/ack.vim#59
@kassio kassio closed this as completed Mar 12, 2014
@gbbr
Copy link

gbbr commented Nov 24, 2014

+1 👍 +1

@Eimis
Copy link

Eimis commented Dec 3, 2014

+1

@ejoubaud
Copy link

ejoubaud commented Oct 1, 2015

cabbrev Ack Ack! just made my life a whole lot easier :)

@Eimis
Copy link

Eimis commented Oct 6, 2015

@ejoubaud thanks!

@htatche
Copy link

htatche commented May 16, 2016

+1

@ches
Copy link
Collaborator

ches commented May 17, 2016

@htatche I don't understand any further +1 on this, there are good solutions above like mappings or an abbreviation (personally I primarily use map <Leader>a :Ack! ''<Left> FWIW). Vim offers a wealth of native configurability like this that obviates the need for plugins to have a thousand settings variables.

The default behavior is not going to change, because a.) it would not be backwards-compatible and this is long-existing, and b.) it mirrors the behavior of :grep and :grep! built into Vim, which is a strong precedent and ack.vim thinly wraps it.

@SamSaffron
Copy link

The reason so many complain about this is cause Ack will always open the bottom window even if top one is in focus, that is a maddening default.

@ches
Copy link
Collaborator

ches commented Jul 4, 2016

@SamSaffron If anyone who finds it maddening would like to work up a pull request to make :Ack! behave more exactly like :grep! in that regard—populating but not opening/focusing the quickfix—I'll gladly consider it. This is a pretty small, straightforward, IMHO fairly well-factored and documented Vim plugin to hack on. I may get around to such a change myself eventually, but not in a particular hurry.

Then, people will probably complain that "I run :Ack! and it doesn't do anything!", or it creates inconsistencies with ack.vim's mappings getting applied to the results windows. I have feelings about that, but.

¯\_(ツ)_/¯

It would be largely a matter of making one function call conditional, aside from the mappings concern… Opening but not focusing the results on ! is probably a viable compromise, also a change likely to involve about three lines.

@SamSaffron
Copy link

I would love to fix this, but even :Ggrep by the demigod @tpope behaves oddly here.

If you have this configuration:

[split1]
[split2]
[quickfix results]

When you click on "quickfix result", stuff is always opened in [split2] regardless of [split1] being the window that just had focus. So my vim voodoo feeling here is that vim does not make solving this easy.

@SamSaffron
Copy link

wow ... I never know about QFEnter, this is soooo useful THANKS!

@ches
Copy link
Collaborator

ches commented Jul 4, 2016

Pardon the topical diversion for those subscribed to notifications, but I've also been made aware of vim-qf as an alternative, it may offer behavior that suits your taste and might compliment ack.vim without conflict, I haven't gotten around to trying it yet.

ches added a commit that referenced this issue Jul 4, 2016
References #59. Thanks @ejoubaud for the succinct abbreviation
suggestion that I wish we documented a long time ago.
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