When a buffer has unsaved deleted/added lines, then any blame
annotations below those lines may be off. Fix this by feeding the
latest buffer contents to Git. Unfortunately there is no easy way
to distinguish between "Unsaved" and "Saved but not committed yet"
so let's keep using the umbrella term.
We double-parse a command definition to figure out the location of
a support script at load time. This feels a bit dangerous and is not
really necessary, so use %val{runtime}/rc/tools/... instead.
Reference: https://lists.sr.ht/~mawww/kakoune/%3CZbOSCK2JjJvo-RTt@gmail.com%3E
Patches as produced by "git format-patch" have a trailing signature
that is separated from the body by a line with "-- " on it. By default
it contains the Git version. We erroneously include this signature
in the diff we pipe to patch, which fails to apply as a result.
Add a targeted fix to suppress these signatures.
Sometimes a patch that fails to apply will apply cleanly after
adding -3. Also sometimes we do want to apply with conflict markers.
So this is another somewhat common option.
Sorry I did not test my earlier patch in production. It passes
blame flags via the environment. On a 5000 line file this results in
"execve failed: Argument list too long" errors.
Use a different way of checking whether blame info is shown.
Since :patch transforms its inputs into context-only lines, we can
easily get into a state where a file diff has only context lines.
git apply does not accept a "diff" without any hunk, so let's skip
that.
It is not an obviously better result than just displaying results
from each tag file, so remove sorting to take advantage of live
completion updates
As discussed in #5081
As of recently, shell script candidate completions are computed in
the background, and displayed incrementally.
Sorting completions means we can't show partial results.
We do this for "ctags-search"; but if there is only one ctags file
there is already a sensible order (which is slightly different than
what GNU sort does). So let's preserve the order in that case.
The number of completions is probably too high for an order to be useful.
Similarly, for "man", sorting is probably not very helpful because
there are so many results.
See https://github.com/mawww/kakoune/pull/5035#discussion_r1413015934
The last update is from 2017, it's pretty outdated. Current
support was combined from existing languages such as Ruby and
Zig and tweaked to fit the Pony language.
When using either of
set-option g completers option=my_option
prompt -shell-script-candidates ...
While the search text is empty, the completions will be sorted
alphabetically.
This is bad because it means the most important entries are not listed
first, making them harder to select or even spot.
Let's apply input order before resorting to sorting alphabetically.
In theory there is a more elegant solution: sort candidates (except
if they're user input) before passing them to RankedMatch, and then
always use stable sort. However that doesn't work because we use a
heap which doesn't support stable sort.
Closes#1709, #4813
prompt has fuzzy filtering which is more discoverable than the menu
mode's regex filtering (because that one needs / to trigger it).
There are no important differences left, so replace the menu builtin
with a prompt-based command.
prompt does not support markup in the completion menu, so drop that
feature for now.
Running an invalid command like "grep -abc" shows no output at all.
Let's give better feedback by showing the error message from grep.
We used to do this until an unrelated change, bd5955c73 (grep: remove
eventual \r, 2013-02-13).
This adds a somewhat discoverable frontend for common uses of the
patch command.
Here are some frequently used commands
# apply selected changes
git apply
# revert selected changes
git apply -R
# stage selected changes
git apply --cached
# unstage selected changes
git apply --cached -R
# apply selected changes and stage them
git apply --index
For everyday use that's a lot of typing so I recommend adding mappings.
One of the features I miss most from Magit/Fugitive/Tig is to
apply/revert/stage/unstage individual hunks or even exactly the
selected line(s). This provides a much more convenient way of
splitting changes than "git add/restore -p".
Implement a "patch" command that applies the selected lines within
a diff by piping them to the "patch" program.
It can also feed other programs like "git apply" (see the next commit).
Original discussion: https://discuss.kakoune.com/t/atomic-commits-in-kakoune/1446
Interestingly, :patch is defined outside the "patch" module. This is
to make it readily available for interactive use.
Putting it into the module does not save any work.
I tentatively added a patch module anyway so we can explicitly declare
this dependency.. although there is the argument that this is not
really needed?
This commit adds `diff_add_char`, `diff_mod_char`, `diff_del_char` and `diff_top_char` as `str` options, with typical
defaults.
This commit also replaces the hard coded +, _, ≃, etc. hardcoded characters in `git update-diff` to use the options from
above.
