Greg Hurrell [Tue, 1 Jun 2021 16:16:22 +0000 (18:16 +0200)]
fix: avoid E874
Seeing this on recent builds, which suggests that maybe the default
regexp implementation has changed lately:
Error detected while processing function corpus#buf_write_pre[2]..corpus#update_references
E874: (NFA) Could not pop the stack!
As `:h NFA` explains:
/\%#= two-engines NFA
Vim includes two regexp engines:
1. An old, backtracking engine that supports everything.
2. A new, NFA engine that works much faster on some patterns, possibly slower
on some patterns.
Vim will automatically select the right engine for you. However, if you run
into a problem or want to specifically select one engine or the other, you can
prepend one of the following to the pattern:
\%#=0 Force automatic selection. Only has an effect when
'regexpengine' has been set to a non-zero value.
\%#=1 Force using the old engine.
\%#=2 Force using the NFA engine.
You can also use the 'regexpengine' option to change the default.
E864 E868 E874 E875 E876 E877 E878
If selecting the NFA engine and it runs into something that is not implemented
the pattern will not match. This is only useful when debugging Vim.
> Just a nit, but I'd lean toward a different default. VertSplit is
> decoration so colorschemes are not designed with the expectation it
> it will be used to render text. It seems more likely than almost any
> other syntax group to be set up with very low or no contrast between
> fg and bg.
Switched to LineNr, semi-arbitrarily (there is no guaranteed highlight
group that is going to look good with all colorschemes, but this one
should at least not look invisible).
Greg Hurrell [Tue, 13 Oct 2020 19:53:04 +0000 (21:53 +0200)]
fix: update listing and preview when there are no matches
Because otherwise the last-seen results we had continue to be shown. So
we need, at a minimum, a `vim.cmd('redraw')`, and we also need to clear
out the preview buffer.
fix: handle edge cases when outside of Corpus directory
Example:
:Corpus <tab>
Expands to:
:Corpus /
If you hit enter there, we don't want to blindly `cd` to "/". In fact we
never want to `cd` to anything with a slash, unless it is a valid Corpus
directory.
:Corpus whatever else
should be taken as a cue to open or create the note "whatever else.md"
in the default corpus directory (the first one in the config).
This means you can hold down a key in the command line and it won't get
laggy. Instead of kicking of blocking serial jobs one after the other,
we cancel the previous job and start a new one. This makes things super
responsive.
Doesn't update when you move yet, because I haven't wired up those
bindings, but it shows correctly on first render and when you change the
command line query.
This might be my JS developer mentality coming through here but I really
want to have clear APIs for dealing with "list"-like tables and
"dict"-like ones, so that's where I'm starting here.
Experimental. Just want to see if it is any faster.
There is some sketchy quoting and concatenation going on here in the
Vimscript, but that's temporary and will go away as the associated code
gets ported.
feat: allow ".md" extension when creating new files
Just say you want to create a file "foo.md" but you already have one
called "food.md"; you can't just type "foo" and hit enter because that
will just open the existing file. If we weren't in the terminal, and we
could actually distinguish between enter and, say, control-enter, then
we could use that as a cue to create the file. But we are in the
terminal, so we instead allow you to type "foo.md". That won't match
"food.md" unless you happen to have that string inside it (unlikely), so
in this way you can add an extension, optionally, as a way of forcing a
unique match and thus creating a new file. Subtle, but useful.
This notes that the Vim plug-in version is now the "official" Corpus
line of development; the code for the JS-powered version can still be
found in the repo history, obviously.
Really, the entire document needs to be rewritten, but I'll have to
tackle that later.
Similar to what we did in 3933f06f97aa537e28a67615211e1d21d930b186, this
is a "trick" merge to replace the "master" branch with the contents of
the "vim" branch, preserving the history of both in the DAG.
First, up, got ready to extract the "vim" branch from my dotfiles repo
as of this commit:
# (Later on, can throw away scratch branch with this...)
git branch -D scratch
In this repo:
git add local path-to-dotfiles
git fresh # an alias to fetch all remotes; ie. git remote update --prune
git show local/scratch # sanity check
git branch vim local/scratch # name branch here too
git checkout vim
git merge -s ours --allow-unrelated-histories master
git commit --amend (to fix message)
Note that to get real history in here, reading it in with:
Finally, will twiddle the branches to point at the right commits (ie.
"master" needs to point at "vim").
* vim:
fix(corpus): make sure we autocommit changes to new files
refactor(corpus): scope command-line mappings more tightly
fix(vim): avoid error on /usr/bin/vim startup
feat(corpus): make it possible to create new files from search
fix(corpus): actually detect backticks
fix(corpus): fix bad fence detection pattern
fix(corpus): remove errant logging
fix(corpus): abort link detection if you run into an adjacent link
refactor(corpus): remove unnecessary "repo" config
refactor(corpus): clean up a code comment
fix(corpus): work around unexpected `git-grep -z` behavior
fix(corpus): store labels case insensitively
style(corpus): fix code formatting
fix(corpus): make sure preview redraws
perf(corpus): make synthetic preview window
perf(corpus): debounce previews
refactor(corpus): remove dead code
fix(corpus): work around for ftdetect not running on first
feat(corpus): approach feature-completeness for initial version
feat(corpus): preview when switching via c-j, c-k
feat(corpus): prototype of typeahead search
fix(corpus): make sure we actually get config when trying to jump
chore(corpus): give up on fancy search/navigation for now
refactor(corpus): lame attempt at making previewing faster
refactor(corpus): revisit preview windows etc
fix(corpus): fix bad deletebufline() call
feat(corpus): support visual mode
feat(corpus): make <C-]> navigate to a link target (or linkify)
feat(corpus): partially sort link reference definitions
feat(corpus): implement crude target transform
feat(corpus): get autolinking working
test(corpus): add some stub tests
feat(corpus): don't manage titles automatically unless autotitle is set
refactor(corpus): deduplicate some logic
feat(corpus): update tags when auto-updating metadata
feat(corpus): update title metadata on save
feat(corpus): add multi-directory configuration
refactor(corpus): start preparing minimal version of Corpus experiment
chore(corpus): enable Corpus experiment but turn it into a no-op
feat: use up/down to move among quickfix results
feat: integrate quickfix list and proper search
feat: use Git to search inside files
feat: add initial experimentation with previews
Greg Hurrell [Fri, 8 May 2020 20:10:27 +0000 (22:10 +0200)]
refactor(corpus): scope command-line mappings more tightly
Although, as noted in the comments, could do this a little more
conservatively. I think I'll just provide settings to override the
mappings so that you suppress them if you want.
On finding first backtick, intent was to find second one, but we just
found the same one again due to our failure to add one to the index.
This broke code span detection, cause this to get improperly treated as
a shortcut link:
foo `baz [bar] boom`
Same problem doesn't occur with links:
foo [bar] baz
Because when we are at "[" and scan ahead looking for "]", there is no
possibility of finding "]" at "[" even without the index increment,
because they obviously don't match.
chore(corpus): give up on fancy search/navigation for now
As noted in the comments, navigating via the quickfix listing is too
slow, any we don't want to pollute the stack with junk anyway.
Trouble is we have fast content search (eg. ":Ack") and fast title
search (eg. ":CommandT"), but we don't have a slick preview mechanism
like we do in the graphical Corpus.
We *might* be able to get something to work nicely with `:pedit` if we
hack deeply into Command-T, but I am not sure I want to do that.
Basically, it would consist of running a search powered by `git grep`
at the prompt (debounced), and basically just using Command-T's
MatchWindow, not its search, and plugging in `:pedit`-based preview
(likely debounced). At first blush, I don't think we want to do any of
that, and might be better off just reimplementing the MatchWindow
functionality from scratch using VimScript alone (and maybe some of the
newer functionality, like floating windows).
This is some early POC code that I wrote a while back. Now that I have a
basic version of the auto-linking working, I think it's time to start
looking at the "navigation/search" side of the equation.