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.
Today I can control "terminal" and "new" by changing the terminal
alias but I always need to choose a concrete implementation, like
"tmux-terminal-horizontal", even when there is otherwise no need to
mention tmux in my config.
Allow to configure windowing system and window placement independently
by introducing dedicated options.
This allows to create mappings that work in any windowing system like
map global user c %{:with-option windowing_placement window new<ret>}
map global user '"' %{:with-option windowing_placement vertical new<ret>}
map global user '%' %{:with-option windowing_placement horizontal new<ret>}
For windowing systems that don't support all placements, you can wrap
the above in try/catch to fall back on the "window" variant which is
defined for all windowing systems.
When using multiple (nested) windowing systems, you might want to
add mappings like
map global user t %{:with-option windowing_module tmux new<ret>}
map global user T %{:with-option windowing_module wayland new<ret>}
---
This changes the default "terminal" alias for some modules. In
particular, instead of delegating to
iterm-terminal-vertical
screen-terminal-vertical
tmux-terminal-horizontal
wezterm-terminal-vertical
it will now by default delegate to the respective "-window" variant.
We could maintain backwards compatiblity here by setting the
"windowing_placement" option accordingly, but the new behavior seems
more logical?
Also, this removes the "terminal-tab" alias which was only defined
by the kitty module.
We could try to keep the alias approach and implement a "with-alias"
command, however that approach can only capture both dimensions
(windowing system and placement) if we add tons of commands
like "terminal-horizontal" (with implied windowing system) and
"tmux-terminal" (with implied placement).
Side thought: we could also get rid of the "focus" alias and instead
define
define-command focus %{
"%opt{windowing_module}-focus"
}
Closes#3943, #4425
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.
This makes Kakoune behave more consistently when using it for Zig.
Empty comments are already auto-removed from the C-family and Python.
In this PR, string literals that start with \\ are not removed in purpose.
modeline-parse leads by matching an expensive regex against the entire buffer,
which can take a long time on huge files.
Perl takes too long on this regex and it seems not even ripgrep
optimizes the \z component
$ ruby -e '10000.times { puts "a" * 10000 }' > big
$ time rg --multiline --only-matching '\A(.+\n){1,5}|(.+\n){1,5}\z' big | wc -l
10
__________________________
Executed in 419.81 millis
usr time 399.84 millis
sys time 20.78 millis
where
$ time kak big -e q
__________________________
Executed in 179.19 millis
usr time 133.61 millis
sys time 53.50 millis
Let's lose the regex.
Fixes#4911
The x11-terminal command spawns a potentially long-lived terminal
process. The terminal can is completely independent of the Kakoune
session that created it.
Due to how it's implemented, the spawned terminals will have
environment variables "kak_opt_termcmd" and "kak_quoted_reg_a"
set. This can be surprising, especially since, by convention, the
environment contains no lowercase variables. Let's stop exporting them.
When launch matches using `id` kitty tries to match against tab id
before matching windows. When there are multiple tabs it's likely to
match a tab before matching a window.
Use `window_id` directly to avoid any possiblity of matching tabs.
This is only needed for `kitty @ launch` for other commands there is
no specific `window_id` field.
This continues the work started by 0a9c90fec (rc: use a separate
*-insert hook to auto-insert comments, 2021-04-17).
The one that's left is Rust but that one is trickier.
Why?
Most users who pass the current selection to grep likely do not intend to pass
the selection as a regex input string.
This makes the grepcmd use an additional -F flag to perform literal-string
matching for the current selection. The -F flag seems to be the standard flag
for literal-string matching in every grep implementation I've found.
