Keep Shortcuts After Closing and Re-Opening Quickfix Window?

[aauren]

Right now, when I initially run :Ack all of the keyboard mappings work correctly, which are awesome by the way. However, when I close the QuickFix window with the keyboard mapping q or by using :cclose and then reopen the QuickFix window with :copen, the keyboard mappings no longer work.

Is there a way to get the keyboard mappings to persist? Barring that, is there a way to use the Ack command to open the previous results?

I saw this issue (#12) and thought that it might be what I need, but it didn't appear to work for me, instead :Ack with no arguments searched what was under my cursor.

[ches]

TL; DR my suggestion for the time being is to install QFEnter and configure it how you like, and set these to ensure that ack.vim stays out of QFEnter's way:

let g:ack_apply_qmappings = 0
let g:ack_apply_lmappings = 0

Now to elaborate, I'm going to lay down a bunch of words here because this very issue has started me on this train of thought in the past, and I might as well write it down to solicit some feedback… I might move this to a separate more topical roadmap issue later, forgive me for the braindump here 😄 I'll leave this issue open until I do that.

Yes, the issue you point out is an annoyance that actually raises philosophical questions about the scope of this plugin—basically, this can't really be fixed unless ack.vim imposed its mappings on Vim's quickfix window all the time, not just when an :Ack search has been invoked. Some users might be okay with that, and even wish for it, but IMO it oversteps the bounds of this plugin.

In hindsight I think this indicates that the quickfix mappings are feature creep, and I feel the right approach is something like QFEnter, a plugin dedicated to providing that functionality for every quickfix window instance in your Vim sessions, which you are deliberately opting into when you choose to install it. Leaving this out could also leave ack.vim open to optionally integrate with Unite.vim for people who may want their search results that way instead of quickfix.

Deprecating and removing this functionality from ack.vim might make many people unhappy though, because it's really about half of what ack.vim actually does 😁 The rest is fairly light wrapping around Vim's built-in 'grepprg' machinery.

Only a little bit of that other half is really even specific to Ack, mainly building the exact ack command and arguments to invoke, and the format of results to parse. We have a fork like ag.vim out there that IMO didn't really need to be a fork, I've been using ag with ack.vim myself for years now with trivial configuration changes.

Pondering these two matters in the past actually led me to start writing a new plugin that takes a different approach, basically one of a generalized standard search command interface with pluggable preset search tool configurations, but I didn't finish yet for several reasons:

1. Available time.
2. I'm not sure it would offer much value over :grep and 'grepprg', which nearly match my above description already… I was still exploring what that value could be. And actually vim-grepper may now be almost exactly what I had in mind.
3. Wondering whether Neovim might eventually make some similar native enhancements to :grep. That could take care of asynchronous search too.

I also did some work on a QFEnter alternative simply because there are some things I don't like about its implementation that would amount to a rewrite if I tried to contribute them. That's beside the point though really, QFEnter does the job and that's why I'm still using it 😄 (Edit: I've since learned about vim-qf also).

(Related to #150, in that removing the quickfix mapping functionality from ack.vim would eliminate that problem…)

[aauren]

Thanks so much for the reply. I think QFEnter is exactly what I'm looking for. Thanks!