Tracking the number of query words that appear as full words in the
candidate seems to fix a few cases where the existing fuzzy matching
algorithm was not great.
I have been running with this for a while and did not notice any
annoyances, the whole RankedMatch code probably deserves more attention
but this seems to go in the right direction.
https://editorconfig.org says
> trim_trailing_whitespace: set to true to remove any whitespace
> characters preceding newline characters and false to ensure it
> doesn't.
We also trim trailing empty lines, which causes unnecessary formatting
discrepancies when working with other tools that implement the specification
only.
This backs out commit 33f44f6abc.
Cc: Jonathan Halmen <jonathan@halmen.org>
sel1 == sel2 was using BasicSelection::operator==, ignoring captures,
which led to selection history deciding that selection did not change
in some cases where only the captures had been updated and for the
new selection not to be properly applied, leading to missing capture.
When blame and blame-jump invoke "git show" they set a BufCloseFifo hook to
display a statusline message and center the viewport.
As mentioned in the previous patch (which fixed a copy-paste error), the
statusline message does not need a NormalIdle hook. Move it to prevent
such errors.
When "git blame" fails, it prints an error message to the status line via
a NormalIdle hook. But the hook is only necessary for "execute-keys vv".
(as a workaround for https://github.com/mawww/kakoune/issues/5082).
Since we run "git blame" in the background, it will not trigger a NormalIdle
hook when finished. This means that the "failed to run git blame" message
will only be shown after the next key press.
This problem can be reproduced by first adding a sleep here:
diff --git a/rc/tools/git.kak b/rc/tools/git.kak
index 05e6ff144..bd899365f 100644
--- a/rc/tools/git.kak
+++ b/rc/tools/git.kak
@@ -301,4 +301,5 @@ define-command -params 1.. \
echo 'echo -markup {Information}Press <ret> to jump to blamed commit'
(
+ sleep .1
trap - INT QUIT
if [ -z "${kak_opt_git_blob}" ]; then
and then running ':git blame' in a file that is not Git-tracked.
Reduce the scope of the hook to show this error message immediately.
Commit e3122ab2c (Refactor prompt history handling, 2023-07-05) was a nice
simplification but it breaks a rare edge case. It suppresses history
recording if all keys the prompt receives were synthesized. That's not
quite the right criteria:
it means that if prompt is created, edited and and executed, all via mapped
keys, we fail to add to history.
The criteria should rather be something like "if all keys the prompt receives
came from synthesized events".
Make it so. This allows us to get rid of the "noninteractive" nested bool
that was only used for disabling history.
My
kak -e 'hook global WinCreate /.* %{ git blame-jump }; edit README.asciidoc'
hangs until I cancel it with <c-c>.
The error is
error while waiting for shell: 1:1: 'evaluate-commands': 3:21: 'execute-keys': no such client: '-draft'
git blame-jump cannot do anything useful without a client in context, so
fail early and explicitly.
Some of our git wrappers use the diff utility; if it's not installed we'll
hang because no one is opening the fifo for reading. For example, this
happens when running
chmod -x $(which diff) &&
kak -e "edit README.asciidoc; git apply"
Fail earlier, I guess -- although it's probably fine as-is.
Running "git blame" in a scratch buffer echoes "Press <ret> to jump
to blamed commit" even though the blaming clearly fails. The failure
is silent because cd_bufdir exits the shell, so we don't even attempt
to run "git blame". cd_bufdir prints a "fail" command stdout but that
goes to /dev/null in this case.
I don't really understand why 891a9f5fe (Merge remote-tracking branch
'lenormf/fix-git-tools', 2019-09-22) moved cd_bufdir inside this
background subshell. I guess it didn't matter as much back then when
we didn't have the "Press <ret> to jump" message. Also the existing
error message printed by cd_bufdir for scratch buffers is confusing.
Fail as early as possible, showing a suitable error. Note that "git blame"
does work in filetype=git-diff and filetype=git-log buffers, so don't attempt
cd_bufdir inside those.
When $PWD is different from $(git rev-parse --show-toplevel, recursive blaming is broken.
For example (assuming k moves to a delted line):
kak -e 'cd src; edit main.cc; git blame-jump; hook -once g NormalIdle .* %{ exec k; git blame-jump }'
Fix this by
1. computing the correct path from diff-parse (we already require
the git command be run in a git directory).
2. passing absolute paths to the recursive "git blame" invocations
I dedicate any and all copyright interest in this software to the
public domain. I make this dedication for the benefit of the public at
large and to the detriment of my heirs and successors. I intend this
dedication to be an overt act of relinquishment in perpetuity of all
present and future rights to this software under copyright law.
I dedicate any and all copyright interest in this software to the
public domain. I make this dedication for the benefit of the public at
large and to the detriment of my heirs and successors. I intend this
dedication to be an overt act of relinquishment in perpetuity of all
present and future rights to this software under copyright law.
file.cc/hh should not know about Context, Buffer, etc... It should
be a pretty low level set of helper functions. Move buffer related
functions to buffer_utils and extract busy indicators to callers.
The code paths around "Missing commit line, assume it is an uncommitted
change" in both blame and blame-jump code look suspiciously similar.
It's possible that we can extract at least something, but there is
a fundamental difference: blame-jump only jumps to another diff,
while blame jumps from diff to blob, which may be a good reason for
keeping them separate.
More specifically, blame-jump passes « $version = "-" » because it's
only interested in the parent commit/file/line, whereas blame wants
to default to using the child commit/file/line (for added and context
lines) and only uses the parent commit/file/line when run on deleted
lines or on uncommitted changes (where HEAD is assumed to be parent
commit even if there is no child).
Unfortunately the blame path forgot to change to use the parent file
for these; fix that and get rid of some code duplication.
Surprisingly, these two commands show different commit times:
git blame README.asciidoc
kak -e 'git blame' README.asciidoc
This is because git shows times as of the original time zone (of the
author/committer). Our blame integration uses the current local time.
- blame-jump displays the date in the status line of a git-show buffer
This date may be inconsistent with the buffer's "Date:" header,
so this seems surprising. Fix that. This fixes a test in some
time zones.
- Unlike "git blame", our ":git blame" does not display time zone
info by default. So, the conversion to localtime might make sense.
I don't really have an opinion on this. Change it too I guess,
since the current behavior might not have been intended.
Fixes#5285
