Greg Hurrell [Sun, 12 Jun 2022 17:08:21 +0000 (19:08 +0200)]
feat: add `g:FerretCommandNames`
Closes: https://github.com/wincent/ferret/issues/75
Note that as usual, I had headaches getting a working `docvim`
installation in order to update the docs.
In 35757c7c9364d940efd8a46877acde04193819c2, the problem was that the
remote site I was trying to update GHC from was suffering from 503
errors, and I was able to get things working on Arch Linux where I had a
working copy lying around.
Today, back on macOS, I tried a few things:
cd $PATH_TO_DOCVIM_PROJECT_DIRECTORY
bin/clean
rm -r ~/.cabal
but every variation of building I tried would fail with a Happy-related
error. As noted here:
https://github.com/haskell/happy
> a pre-built Happy is required to build the full version of Happy
I first tried to do this on my macOS machine, but seems all my
Stack/Haskell tooling got borked in the move to Monterrey. I did a `brew
reinstall ghc` and `brew reinstall stack` there, but `bin/build` dies
trying to download a version of GHC, as shown by these excerpts:
fix: avoid E42 error when deleting last quickfix entry
After deleting the last item in the quickfix listing using Ferret (eg.
with `dd`), we would try to go to the next entry, but given that there
is none, Vim would print:
Greg Hurrell [Sat, 29 Jan 2022 22:57:42 +0000 (23:57 +0100)]
fix: rg v13.0.0 hang when passing additional options that take arguments
Given a command like:
:Ack TODO --type go
The logic would see:
- `TODO` and consider it a search term
- `--type` and consider it an option
- `go` and consider it a path
And so fail to append the necessary ".", causing `rg` to fail in Neovim
as described in:
https://github.com/wincent/ferret/issues/78
One workaround is to explicitly add the ".":
:Ack TODO --type go .
Another is to force Ferret to see `--type go` as a single option and
not an option-followed-by-a-path with:
:Ack TODO --type=go
This commit attempts to avoid the need for such workarounds by teaching
Ferret about which commands go with arguments. The solution is by no
means perfect, as we are _not_ implementing a full options parser, but
in my brief testing it at least mitigates the worst symptom of the
problem; namely, the rather unpleasant and inscrutable error:
Error detected while processing function ferret#private#ack[11]..ferret#private#nvim#search[1]..ferret#pri
vate#nvim#cancel:
line 3:
E474: Invalid argument
These aren't strictly needed because you can make your own mappings
without them, but the fact that they don't exist may cause confusion,
even for me, as seen in the related issue.
Side note: I'm hacking on a Rust rewrite of `docvim` on this machine
(the Arch Linux box), so I needed to switch back to the `haskell` branch
to be able to generate these updates. These are the commands I ran:
Bit worried that might stop working in the future because it is not
statically linked and I'm not confident that I'll be able to build this
package again in the future:
docs: prepare HISTORY section for further development
Normally I would initialize this lazily when I make the next change, but
doing it eagerly this time because I just installed a pre-push hook for
this repo on this machine that will keep `main` and `master` in sync
whenever I push, and I want to see it working...
As explained in the comment, if we add "." to the `rg` invocation in
order to work around the new behavior, we wind up with ugly results in
the quickfix listing:
./a/b/c
instead of:
a/b/c
My first thought was to just transform these back whenever the hack is
in effect, but I figured I may as well do it any time the user passes
"." or "./" explicitly too (something that users who have run into the
new `rg` behavior may already have muscle memory for doing).
Now, I could apply this to the other search modes (eg. "async" Vim mode
and "vanilla" mode) for consistency, but the truth is I suspect almost
nobody is using those, and if they are, they are probably not in the
habit of appending "." to their searches (because there is not need to).
v13.0.0 broke a number of tools in Neovim, but not in Vim, as described
here:
https://github.com/BurntSushi/ripgrep/issues/1892
My reading of that is that changes to Neovim will/may be required,
because the `rg` author is right that rg's handling is "technically
correct" and I don't think he's going to change it. Luckily, we don't
have to take sides in that argument because there is a straightforward
enough workaround of always providing a path to search (ie. ".", only if
one isn't already provided by the user).
installing and building docvim on this machine (in order to include the
update to the "HISTORY" section in the docs) is a frickin' ordeal. It
takes:
1. 5.53s to clone the repo.
2. 3m56s to install GHC.
3. 3m24s to build the project.
4. 1.64s to run the built tool.
Which seems massively out-of-proportion for something that clocks in at
1,380 lines of Haskell according to `sloccount`. On the upside, this is
one of the few tasks I can throw at this Linux box that actually taxes
the machine. 😆
Greg Hurrell [Mon, 10 Jun 2019 08:12:30 +0000 (10:12 +0200)]
fix: loosen regex that checks for appropriate :Acks argument
Recent changes introduced trailing whitespace here, which is causing the
regex not to match. It seems that neither leading nor trailing
whitespace can cause any harm though, so accept both.
Greg Hurrell [Mon, 11 Mar 2019 14:19:35 +0000 (15:19 +0100)]
Avoid capturing bad 'scrolloff' value
I was finding that my 'scrolloff' was getting permanently set to zero in
the following scenario and perhaps in others:
1. Search for something; the quickfix window gets shown and we save the
current 'scrolloff' value.
2. Move focus to the quickfix window, at which point we set 'scrolloff'
to 0.
3. Initiate another search; when the new results show up, we save the
current value of 'scrolloff' (0), overwriting the real value that we
originally saved.
The simplest fix, then, seems to be this one: only capture the value
the first time we show the window. This means that if you update the
value and we later do a search, we won't capture the new value, but that
seems less likely to happen than the scenario which we're talking about
in this commit, which happens all the time.
Greg Hurrell [Thu, 31 Jan 2019 21:37:32 +0000 (22:37 +0100)]
Fix bad args passed to ferret#private#complete()
As far as I recall, I am supposed to be passing the command name in
here. I think this has been wrong since these lines were added, in 6c21ea462e62fc3022c63580f3bc92.
Greg Hurrell [Fri, 4 Jan 2019 09:03:02 +0000 (10:03 +0100)]
Handle repeated 'g' flags passed to :Acks
This is amazingly edge casey, but the 'g' flag can be repeated, toggling
the effect each time. So:
:Acks /foo/bar/gggg
Would actually have the effect of turning off global replacement. As bf9bffbc21ad3 said:
The docs for `:Acks` promise that:
> Takes all of the files currently in the |quickfix| listing and
> performs a substitution of all instances of {pattern} (a standard
> Vim search |pattern|) by {replacement}.
So in order to be true to the promise of replacing "all instances" we
need to make sure that there is only a single 'g' flag.
Greg Hurrell [Fri, 4 Jan 2019 08:50:59 +0000 (09:50 +0100)]
Handle 'gdefault'
The docs for `:Acks` promise that:
> Takes all of the files currently in the |quickfix| listing and performs a
> substitution of all instances of {pattern} (a standard Vim search |pattern|)
> by {replacement}.
So, that means that we should handle `'gdefault'` being set, which would
otherwise invert the meaning of the 'g' flag to `:substitute` and cause
only the first instance on each line to be replaced.
Greg Hurrell [Thu, 20 Dec 2018 22:01:32 +0000 (23:01 +0100)]
Merge branch 'pull/57'
Closes: https://github.com/wincent/ferret/pull/57
* pull/57:
Apply style fixes for consistency
doc: update AUTHORS and HISTORY
Set the list's 'title' with last search string
Jon Parise [Thu, 20 Dec 2018 16:39:21 +0000 (08:39 -0800)]
Set the list's 'title' with last search string
We create the list using e.g. `cexpr`, which implicitly names the list
after the command that created it. We can provide a more descriptive
title by setting the list's 'title' field (in vim 7.4.2200+) or setting
w:quickfix_title as a fallback (just for the quickfix list).
Greg Hurrell [Tue, 13 Jun 2017 04:09:39 +0000 (21:09 -0700)]
Add g:FerretAutojump
This is a fairly invasive change, so I'll keep my finger poised above
the revert button. For more context, see:
https://github.com/wincent/ferret/issues/21
Notable changes since I last explored this:
- Using `winnr()` to avoid blindly relying on `wincmd p`.
- Switched to `:copen` (from `:cwindow`) to get consistent focusing
behavior.
- Slight change of `post()` callback ordering so that we can decide
whether or not to open the listing at all; this allows us to avoid
showing an empty listing with `:copen`.
Greg Hurrell [Fri, 9 Jun 2017 02:32:47 +0000 (19:32 -0700)]
Drop support for vim-dispatch
Supporting it is just too painful given the degree of difference between
vim-dispatch and the other environments, especially considering how
vim-dispatch can run with one of any number of underlying strategies.
Given the prevalence of Vim 8 and Neovim nowadays (with async support),
the value is no longer compelling here. So let's just drop it in order
to move faster. Life is too short.
Greg Hurrell [Fri, 9 Jun 2017 02:03:49 +0000 (19:03 -0700)]
Improve backslash handling
When searching *for* a backslash, our use of `<f-args>` was causing
confusion because of its special behavior with respect to backslashes.
According to `:h <f-args>`:
- Arguments get split on spaces.
- "\ " prevents a space from causing a split.
- "\\" gets replaced with "\".
- "\x" remains unmodified.
So that means searching for "foo\\bar" would turn into a search for
"foo\bar" (which means "foo, word-boundary, ar").
Fix this by replacing `<f-args>` with `<q-args>`, requiring us to do
argument splitting ourselves, using the nastiest regex ever. That one
was fun to write...
git.wincent.com / ferret.git / log
