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.
