| Age | Commit message (Collapse) | Author |
|---|
|
We have only one place where we handle actual keys typed by the user.
|
|
Since shell-script-completions now runs the script asynchronously
and unconditionally, there is no use for the CompletionFlags::Fast
anymore which means we can remove that type altogether.
|
|
|
|
Move more code into the implementation files to reduce the amount
of code pulled by headers.
|
|
Make last insert and macro recording closer together, paving the
way towards moving last insert to a register.
Use a FunctionRef for insert completer key insertion support.
|
|
|
|
As @topisani pointed out in #5131, it is more user friendly to always
provide a %val{register} and %val{count} regardless of the mode.
|
|
This should implement what #5131 proposed in a different way.
Closes #5131
|
|
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.
|
|
Read output from the script as it comes and update the candidate
list progressively.
Disable updating of the list when a completion has been explicitely
selected.
|
|
ensure cursor is visible after user input except if the command
implementation opted-out. Hooks and timers should not enforce
visible cursor.
PageUp/PageDown and `<c-f>` / `<c-b>` commands still move the cursor
as this seemed a desired behaviour.
|
|
|
|
My terminal allows to map <c-[> and <esc> independently. I like
to use <c-[> as escape key so I have this mapping:
map global prompt <c-[> <esc>
Unfortunately, this is not equivalent to <esc>. Since mappings are
run with history disabled, <c-[> will not add the command to the
prompt history.
So disabling command history inside mappings is wrong in case the
command prompt was created before mapping execution. The behavior
should be: "a prompt that is both created and closed inside a
noninteractive context does not add to prompt history", where
"noninteractive" means inside a mapping, hook, command, execute-keys
or evaluate-commands.
Implement this behavior, it should better meet user expectations.
Scripts can always use "set-register" to add to history.
Here are my test cases:
1. Basic regression test (needs above mapping):
:nop should be added to history<c-[>
---
2. Create the prompt in a noninteractive context:
:exec %{:}
now we're back in the interactive context, so we can type:
nop should be added to history<ret>
---
3. To check if it works for nested prompts, first set up this mapping.
map global prompt <c-j> '<a-semicolon>:nop should NOT be added to history<ret>'
map global prompt <c-h> '<a-semicolon>:nop should be added to history first'
Then type
:nop should be added to history second<c-j><c-h><ret><ret>
the inner command run by <c-j> should not be added to history because
it only existed in a noninteractive context.
---
See also the discussion https://github.com/mawww/kakoune/pull/4692
We could automate the tests if we had a test setup that allowed
feeding interactive key input into Kakoune instead of using
"execute-commands". Some projects use tmux, or maybe we can mock
the terminal.
|
|
Text pasted into Kakoune's normal mode is interpreted as command
sequence, which is probably never what the user wants. Text
pasted during insert mode will be inserted fine but may trigger
auto-indentation hooks which is likely not what users want.
Bracketed paste is pair of escape codes sent by terminals that allow
applications to distinguish between pasted text and typed text.
Let's use this feature to always insert pasted text verbatim, skipping
keymap lookup and the InsertChar hook. In future, we could add a
dedicated Paste hook.
We need to make a decision on whether to paste before or after the
selection. I chose "before" because that's what I'm used to.
TerminalUI::set_on_key has
EventManager::instance().force_signal(0);
I'm not sure if we want the same for TerminalUI::set_on_paste?
I assume it doesn't matter because they are always called in tandem.
Closes #2465
|
|
They are quite different use cases, and this allow moving InsertMode
to input_handler.hh which is what uses it.
This also cleans up the code as we can get rid of get_insert_pos and
rely more on SelectionList::for_each.
|
|
|
|
The prompt and autocomplete normally wait for `idle_timeout` before showing
suggestions, however commands like `g`, `v`, or the lead-key show Clippy
instantly.
This fixes the issue by making `on_next_key_with_autoinfo()` wait for
`idle_timeout` before displaying suggestions.
Fixes mawww/kakoune#3365
Fixes mawww/kakoune#2066
|
|
|
|
Currently expose an additional name, the format is up for
discussion.
Fixes #1855
Fixes #2569
Fixes #2672
|
|
|
|
Closes #2052
|
|
|
|
|
|
|
|
|
|
Fixes #2042
|
|
|
|
Move recording of keys to the input handler itself instead of the
Insert mode so that eventual nested modes (potentially introduced
by <a-;> will get their keys recorded as well).
Fixes #1680
|
|
|
|
Fixes #1654
|
|
|
|
The need to have the array size in the return type was redundant with
the actual list of elements.
|
|
Fixes #1465
|
|
Fixes #1318
Also fixes https://gitlab.com/gnachman/iterm2/issues/5408
|
|
This way we dont depend on knowing the base template to enable bit ops
on an enum type.
|
|
Introduce Meta::Type<T> to store a type as value, and pass it
around, migrate enum_desc and option_type_name to this.
|
|
|
|
Closes #896
|
|
Fixes #873
|
|
For regex prompts we actually want to save them, as a leading space
is significant
Fixes #767
|
|
Fixes #749
|
|
Fixes #660
|
|
|
|
Fix #551
|
|
Client can now update menu/info positions when the window move
around.
|
|
Fixes #528
|
|
Fixes #495
|
|
|
|
Support the value1|value2|value3 syntax for flag options.
|
|
|
