Bundler 2.3.5 is running, but your lockfile was generated with 2.0.2. Installing Bundler 2.0.2 and restarting using that version.
...
Using bundler 2.0.2
Following files may not be writable, so sudo is needed:
/var/lib/gems/3.0.0
/var/lib/gems/3.0.0/build_info
/var/lib/gems/3.0.0/cache
/var/lib/gems/3.0.0/doc
/var/lib/gems/3.0.0/extensions
/var/lib/gems/3.0.0/gems
/var/lib/gems/3.0.0/plugins
/var/lib/gems/3.0.0/specifications
Fetching diff-lcs 1.3
/var/lib/gems/3.0.0/gems/bundler-2.0.2/lib/bundler/shared_helpers.rb:36: warning: Pathname#untaint is deprecated and will be removed in Ruby 3.2.
ArgumentError: wrong number of arguments (given 2, expected 1)
An error occurred while installing diff-lcs (1.3), and Bundler cannot continue.
Make sure that `gem install diff-lcs -v '1.3' --source 'https://rubygems.org/'`
succeeds before bundling.
In Gemfile:
rspec was resolved to 3.9.0, which depends on
rspec-expectations was resolved to 3.9.0, which depends on
diff-lcs
Greg Hurrell [Tue, 13 Dec 2022 20:02:36 +0000 (21:02 +0100)]
chore: update actions config to avoid deprecation warnings
Node.js 12 actions are deprecated. For more information see:
https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/.
Please update the following actions to use Node.js 16:
actions/checkout@v2,
actionsx/prettier@v2,
JohnnyMorganz/stylua-action@1.0.0
ubuntu-latest workflows will use ubuntu-22.04 soon. For more details,
see https://github.com/actions/runner-images/issues/6399
No new release of `actionsx/prettier` action yet, but I updated the
others.
I first suspected a bad cached value, and that may be the case, but
either way, the arithmetic here seems off, as it will allow a bad format
to occur whenever `width` is, say, 103 (`width` usually comes from
a `Window` instance, with `vim.o.columns` used as a fallback).
I was finally able to repro by setting `margin` to `1` and then
adjusting my window size until `'columns'` was (I think) 107.
Replace hacked-together config validation with something a little more
robust. This is like `vim.validate()` but "more". Currently only lightly
tested.
- If I pushed to a branch, without making a PR, actions would run once.
- If I pushed to a branch, then opened a PR, actions would run twice.
- If somebody else opened a PR (from a fork), actions would run once.
After:
- If I push to a branch, without making a PR, actions will run once.
- If I push to a branch, then open a PR, actions will run once (ie. due
to the push, not the PR).
- If somebody else opens a PR (from a fork), actions will run once.
refactor: reduce duplication in scanner benchmarks
More duplication in the stubbing (which is fine), and less duplication
in the scanner set-up (which is good to reduce, because we don't want
this drifting out of sync).
These are obviously fragile because they repeat a fair chunk of the
implementation of each scanner. I wanted to avoid requiring the main
`init.lua` file, but I might try that out anyway in the next commit as I
suspect it will be the lesser of two evils.
Replaces 5 custom finders/scanners with default config that just calls
the list and command scanners. Primary motivation here is to dogfood the
extension mechanisms, but the obvious secondary benefit is that it DRYs
up a lot of duplication.
This breaks the scanner benchmarks so I've commented them out. I will
fix them in the next commit (or soon after).
Sorry for the uselessly abstract subject line. What's actually happening
here is this:
- Move `fnameescape()` call into `commandt.open()`. The only finder that
won't use this is the `help` one, which provides its own. Everything
else can assume it is working with files.
- Hoist `commandt.open()` up into a local `open` variable so it can be
declared before `default_option` ans assigned there; note that we're
getting rid of one layer of indirection here.
- Simplify most finders, now that they don't need to call
`fnameescape()` themselves.
This probably isn't the final API, but wanted to show how you could add
an arbitrary scanner + finder that lets you supply a list of candidates
and then implement a pretty novel "open"-ing scheme.
local has_commandt, commandt = pcall(require, 'wincent.commandt')
if has_commandt then
commandt.setup({
-- Demo: mimic the old CommandTLine scanner + finder.
finders = {
line = {
candidates = function()
local lines = vim.api.nvim_buf_get_lines(0, 0, -1, false)
local result = {}
for i, line in ipairs(lines) do
-- Skip blank/empty lines.
if not line:match('^%s*$') then
table.insert(result, vim.trim(line) .. ':' .. tostring(i))
end
end
return result
end,
open = function(item, _kind)
-- Extract line number from (eg) "some line contents:100".
local suffix = string.find(item, "%d+$")
local index = tonumber(item:sub(suffix))
vim.api.nvim_win_set_cursor(0, {index, 0})
end,
},
},
})
-- :CommandTLines (named so as not to clash with :CommandTLine).
vim.api.nvim_create_user_command('CommandTLines', function(command)
require('wincent.commandt').finder('line', command.args)
end, {
nargs = 0,
})
end
but here I'm going with something a little less descriptive:
CommandT [fallback]
seeing as the extra detail in the title doesn't tell you _what_ went
wrong; really, all we can do here is show a hint that _something_ went
wrong, so we might as well be brief about it.
Two things to note about implementation:
- One is that I am playing around here trying to figure out how much
metatable magic I want in here without making it all too "clever". So
here I have a `__newindex` implementation that allows us to write
`prompt.name = 'fallback'` instead of `prompt:set_name('fallback')`.
The former is visually cleaner, but I don't necessarily like that it
hides the fact that an imperative side-effect is going to take place.
I will probably "dumb this down" as opposed to trying to use the
pattern in other places in a uniform way.
- The other is that my earlier claims about top-down React-style
dataflow are pretty much not true any more. It _was_ true at the
start, when each component rendered using data passed into it; now we
have muddied the waters considerably with imperative methods. I will
almost certainly want to revisit this topic in the future.
fix: make watchman scanner work with path argument
Although the wisdom of making heavy use of this functionality is dubious
(because as you add more watches to Watchman, the slower it gets,
especially in the case of nested projects under a shared root, if my
experience with running the benchmarks is anything to be believed).
Note that this is a display-only thing, to stop undesired wrapping and
other visual distortions. You can't actually type "Icr" and expect it to
match the file (these is no "r" in the name), although you can open it
by accepting the selection.
> We teach the callers to interpret an empty result list as a cue to
> try again using a fallback mechanism; in an empty directory this would
> give a false negative but a relatively harmless one (ie. you might run
> `:CommandTRipgrep` in an empty folder, and Command-T would take that as
> a cue to try again with the standard scanner, which would of course
> also return an empty list).
Specifically, we do this whenever `git`, `rg`, or `find` returns no
results.
There is a bit of duplication here because we need thunks at each site;
otherwise as soon as we `require`-d the fallback finder it would do a
redundant scan. I'm not going to factor that out yet because I am still
not convinced that this is an optimal strategy. Want to let it bake for
a while and see what happens.
> we may also want to swallow `stderr` so it doesn't leak back in any
> visible way (ie. that would mean changing a call to `git ...` into
> `git ... 2> /dev/null` etc). The only catch is that this may make
> trouble-shooting harder (users could edit out or change the redirect,
> I guess).
So, yeah. This is a double-edged sword, but in the next commit I am
planning on dulling at least one of those edges by implementing a
fallback behavior for each of these scanners.
Greg Hurrell [Tue, 30 Aug 2022 06:53:48 +0000 (08:53 +0200)]
Merge branch 'wincent/fix-32-bit'
* wincent/fix-32-bit:
docs: update HISTORY section
fix: add missing `-D` prefixes when building on 32-bit architectures
docs: start new heading for next release under HISTORY
the only place tabs matter is in the rules, but we may as well use tabs
everywhere. We could also use spaces; it would work just the same.
Indenting does make it more readable, although it does bust the syntax
highlighting in Vim a little bit, so I guess _somebody_ out there thinks
you should not be using indents for non-rule parts of the Makefile.
I would use something like git.git's Makefile as a guide, but it uses
both indented and unindented conditional bodies. 🤷
Greg Hurrell [Mon, 29 Aug 2022 19:42:12 +0000 (21:42 +0200)]
fix: use smaller memory allocation values on 32-bit systems
To deal with the aborts reported in:
https://github.com/wincent/command-t/issues/399
My theory was that on a 32-bit machine an allocation was failing due to
the rather generous sizes involved, given that the DEBUG build showed
the tests passing, and some allocations were recorded in the
`commandt-debug.log`
We tried with smaller sizes (1/4 of the previous sizes) and the aborts
went away. These sizes are still ridiculously large. The smaller sizes
correspond up to 32 million candidate strings (the largest projects I've
ever worked with or even heard of had anywhere between 1.5 M and 4 M
strings; I expect that anybody working on anything larger than that is
very, very likely running on a 64-bit architecture), and a string
storage slab of 32 G (the way the math works out here is if you had 32 M
strings of length 1K you'd fill up all the space).
So, in this commit, we do some basic autodetection based on `getconf
LONG_BIT` (which is POSIX, so should be relatively portable, even if it
isn't super informative) and use that to decide how big the numbers
should be.
We may still want to make this overridable by users, or otherwise more
sophisticated, but until I see a demand for that, I'll hold off.
The `compile_flags.txt` file is so that `clangd` can know what the
preprocessor options are going to resemble (obviously, these are
hard-coded, so really are just intended to keep the LSP from complaining
about undeclared identifiers).
Greg Hurrell [Sun, 28 Aug 2022 15:42:03 +0000 (17:42 +0200)]
fix: fix rendering glitches due to interaction with vim-dirvish
This isn't a bug in vim-dirvish, but there is something about the way it
operates that triggers this undesired behavior in Command-T. The repro
isn't 100% reliable but it almost is:
1. Create a tmux split in order to have a narrow window to test inside.
2. Open vim-dirvish with `nvim .`.
3. Split the buffer vertically to make it even thinner (strictly
speaking, you don't have to do this, but it makes it more likely to
reproduce).
4. Open Command-T; see that the match listing is acting as though it
were scrolled to the right (ie. you can't see the text on the left,
or you can only see the tail end of it).
Now, what vim-dirvish is doing is having potentially very long absolute
paths in its buffer that are very wide, and hiding the bit that
corresponds to the current working directory using Vim's "conceal"
feature. So, you only see relative paths (relative to the current
working directory), but each line in the buffer may be much longer.
So, given a `'textwidth'` of, say, 80, it's easily possibly for you to
have lines longer than that, even if they don't look that long. This
becomes more obvious if you set `'colorcolumn'` to "+0,+1" etc; you
might have a path that looks like "README.md" in the visible spectrum,
but the line is actually prefixed by something way longer, and you can
see the colorcolumn columns not in column 80 (assuming `'textwidth'` is
80) like you would expect, but in something way farther to the left,
like "column" 15 or 20.
If you jump the cursor all the way to the start of the line (with `^`)
then you see the colorcolumn highlighting move to the right, and
Command-T works without the rendering glitch. If you jump to the end
(with `$`), the colorcolumn highlighting moves back to the left and the
bug returns.
I tried various settings of `'sidescroll'` and `'sidescrolloff'` but the
only way I could get the problem to go away was to turn `'wrap'` _on_,
and then trim my lines to avoid the unwanted wrapping. Moving the cursor
to column 0 with `nvim_win_set_cursor` does not solve this problem, even
thought he docs say it will scroll the window if necessary (note: we
were already doing this).
I tried to repro this without vim-dirvish, and didn't succeed. For
example I got a big Markdown file with long lines and tried various
values of all the settings without reproducing the bug. I turned off
various bells and whistles. I updated vim-dirvish. In the end, I don't
have a smoking gun, but I have a correlation. It's a mystery how the
state of the vim-dirvish window could/would affect an independent buffer
(the match listing); that does feel like a bug, in Neovim most likely.
But it seem so edge-casey and speculative that I don't think I can even
formulate a bug report.
Greg Hurrell [Sun, 28 Aug 2022 12:57:57 +0000 (14:57 +0200)]
docs: add back link to canonical upstream
This walks back the change I made in 10992d821b156b6c ("Remove
references to wincent.com product pages and repo", Jan 19 2016) a little
bit. I wanted to emphasize GitHub because that's where everybody clones
from (or should clone from), but it feels like mentioning the canonical
upstream is technically the right thing to do.
Greg Hurrell [Sun, 28 Aug 2022 12:44:57 +0000 (14:44 +0200)]
refactor: get rid of Rake
There are bin scripts for doing most of the stuff you could do from
Rake:
bin/check-format Check formatting of C, Lua, and Markdown files
bin/create-archive Create ZIP archive from tagged HEAD
bin/format Format C, Lua, and Markdown files
bin/help Show this usage information
bin/spec Run Ruby specs
bin/test Run Lua tests
And a top-level Makefile for the common operations:
make build compile
make check run prerelease checks (clean, build, run tests, check style, check tag)
make clean remove build artifacts
make help show this help
make test run tests
The user in question is loading Command-T like this, using packer:
use {
'wincent/command-t',
run = 'cd lua/wincent/commandt/lib && make',
config = function()
vim.g.CommandTPreferredImplementation = 'lua'
require('wincent.commandt').setup({})
end
}
and they see this whenever they run `:PackerCompile`:
commandt.setup():
`commandt.setup()` was called after Ruby plugin setup has already run
So, I'm removing this check as it doesn't add a lot of value. My advice,
then, is to move this statement:
vim.g.CommandTPreferredImplementation = 'lua'
up into the top-level of the `~/.config/nvim/init.lua`. That way,
whenever Command-T's `plugin/command-t.vim` is sourced, it will do the
right thing, which means:
1. Skip doing anything if `command_t_loaded` is already set.
2. Do Lua-centric set-up instead of Ruby-centric set-up.
And then when `plugin/command-t.lua` is sourced (which will always
happen second, because Neovim loads Lua _after_ Vimscript), it will
again do the right thing (ie. do the Lua-centric instead of Ruby-centric
set-up).
Greg Hurrell [Sat, 27 Aug 2022 16:50:02 +0000 (18:50 +0200)]
refactor: "expose" `ui.open()` function
This is still a private function and I won't be adding it to the docs as
officially supported API, but I want to provide this as a temporary
workaround for the problem reported here:
has a bug in it because it hasn't been touched since February 2019, and
it wasn't written to account for the fact that Neovim mappings can now
map to Lua callbacks instead of Vimscript strings (ie. via the
`vim.keymap.set()` call). So, it has some code that does this:
let info = maparg('<CR>', 'i', 0, 1)
if empty(info)
let old_cr = '<CR>'
let is_expr = 0
else
let old_cr = info['rhs']
" ... etc
It sees our `<CR>` mapping and dies because it assumes that the returned
`info` has a `'rhs'` key, but it doesn't:
E716: Key not present in Dictionary: "rhs"
This commit, then, allows us to make a workaround by replacing the Lua
callback with a string-based mapping which _will_ have a RHS:
ie. we replace the standard mapping, which maps to the internal `open()`
callback, with one that imperatively reaches in from the outside and
calls it as seen above.
Like I said, I won't be making this an official API, but I did want to
provide a workaround, seeing as it may be a while before auto-pairs gets
updated.
Greg Hurrell [Sat, 27 Aug 2022 08:51:28 +0000 (10:51 +0200)]
docs: remove reference to `g:CommandTSuppressRubyDeprecationWarning`
I never implemented this because I realized that if you are going to
set:
let g:CommandTSuppressRubyDeprecationWarning=1
you may as well just do:
let g:CommandTPreferredImplementation='ruby'
so, the suppression setting is pointless. I also abandoned my plans of
showing the message only once (ie. by writing something to disk) as not
worth the complexity — too many edge cases.
Greg Hurrell [Sat, 27 Aug 2022 08:46:32 +0000 (10:46 +0200)]
fix: apply consistent prefix
When Lua is _not_ the preferred implementation, use `KommandT` prefix
for everything. For some reason, probably a copy-paste error or
something, I had `CommandTRipgrep` instead of `KommandTRipgrep`, unlike
all the others.
Greg Hurrell [Fri, 26 Aug 2022 22:08:43 +0000 (00:08 +0200)]
chore: remove unused config file
Some more cleanup following on from df1471519a6bfef1 ("chore: remove
vendor/vimscriptuploader", Jul 24 2022), which said:
> Last reference removed in 9c7f81208a32fe4d ("chore: battle bit-rot in
> gem dependency graph", May 9 2020). I've been manually uploading
> releases since then.
This config file was added all the way back in b47221fb41922260
("Rakefile: tweaks to get vimscriptuploader.rb working", Mar 26 2011)
and was never touched again, until now.
Greg Hurrell [Fri, 26 Aug 2022 22:03:13 +0000 (00:03 +0200)]
refactor: mostly clean out Rakefile
We're not going to be cutting Ruby releases from this branch any more
(see `5-x-release` for that), so most of this file becomes irrelevant.
As noted in the "TODO" comments, I want to remove the release-y bits out
of the Rakefile in a future commit (at which point all it will really be
for is to run the specs, and to be honest, if that just amounts to
`bundle exec spec` I may end up getting rid of the whole file).
I doubt anybody running these tests is on such an old version at this
point, so it seems safe to switch to `Integer`.
Removed the comments because I am not certain whether we're going to hit
that first `if` branch's body any more, and I'd rather have no comments
than something inaccurate or misleading.
Greg Hurrell [Fri, 26 Aug 2022 21:57:05 +0000 (23:57 +0200)]
test: avoid deprecation warnings
WARNING: An expectation of `:number` was set on `nil`. To allow
expectations on `nil` and suppress this message, set
`RSpec::Mocks.configuration.allow_message_expectations_on_nil` to
`true`. To disallow expectations on `nil`, set
`RSpec::Mocks.configuration.allow_message_expectations_on_nil` to
`false`. Called from spec/command-t/controller_spec.rb:87:in `stub_vim'.
refactor(lua): log in DEBUG builds if `pclose()` fails
May as well do _something_ here, seeing as we have this splendid `if`,
otherwise I may as well just ignore the return status and write the
whole thing as:
I could hoist the declaration up the top, but in general I have been
keep declarations close to their usage sites, so I am just inserting a
no-op statement at the label instead.
git.wincent.com / command-t.git / log
