Closed nugend closed 6 years ago
I can’t reproduce.
I'm running Kakoune v2018.09.04 installed through brew. The debug buffer says I don't have gocode, goimports, or gogetdoc installed
I just tried updating to the latest version of the plugin (aa64d0) and the space inside parens issue has been cleared up but I'm still seeing the issue with "o".
Here's the kakrc I'm using:
source "%val{config}/plugins/auto-pairs.kak/rc/auto-pairs.kak"
hook global WinCreate .* %{ auto-pairs-enable }
I did install the plugin using @andreyorst's plugin manager, but I disabled it to find a minimal config.
I'm a little new to Kakoune. I tried to find info on how to debug issues, but didn't find much info on how to debug this sort of thing in the manual when I went looking for it. Maybe you could make a suggestion where to do some reading to find out what's happening?
Maybe auto-pairs
is not POSIX somewhere. :thinking:
Oh, maybe this helps. When in insert mode, if I hit enter to insert a newline, two newlines are added.
Maybe
auto-pairs
is not POSIX somewhere. 🤔
I also can't repro, and I use dash (because I can't get people's attention on https://github.com/mawww/kakoune/issues/2152, sigh), which is very close to plain POSIX shell. So I think the issue is somewhere else.
GNU Bash 3.2.57(1)-release x86_64-apple-darwin18 if that helps. OS X 10.14
Guess that's an old version?
@alexherbo2 3446121 did not resolve the issue I am seeing.
I took a stab in the dark and added "-draft" to the execute-keys
command in auto-pairs-insert-new-line
and that seems to have fixed both newline issues (the "o" key problem and the double newline when hitting enter in insert mode).
I'm not 100% sure I understand what that flag does though!
define-command -hidden auto-pairs-insert-new-line %{ try %{
auto-pairs-try-execute-keys '\\Q%s\\E\\n\\h*\\Q%s\\E' ';KGl<a-k>%s<ret>'
execute-keys --draft <up><end><ret>
}}
I did install the plugin using @andreyorst's plugin manager, but I disabled it to find a minimal config.
Can you show your config, so I could verify if you did something wrong with plug.kak configuration, so I could update the docs accordingly?
Please see the config here: https://github.com/alexherbo2/auto-pairs.kak/issues/16#issuecomment-429668971
The repo was just cloned into that location (which is the only thing the plugin manager does as far as I can tell).
which is the only thing the plugin manager does as far as I can tell.
plug.kak does many things to strip away plugin maintaince from user to plugin manager. I was interested how did you configured your kakrc
with it, since maybe you've used wrong configuration at some point. If everything is set up correctly, plug
command, tries to detect if plugin is installed, and sources the script files from the repo for you.
My config for auto-pairs.kak:
plug "alexherbo2/auto-pairs.kak"
evaluate-commands %sh{
[ -z "${kak_opt_plug_loaded_plugins##*auto-pairs.kak*}" ] || exit
echo "hook global WinCreate .* %{ auto-pairs-enable }"
echo "map global user -docstring 'surround selection' 's' ': auto-pairs-surround<ret>'"
}
After that I'm able to use plugins, and my initialization won't fail if auto-pairs.kak isn't installed.
I don't think that the problem here is with my plugin manager, just wanted to see if anything wrong in the configuration.
Ah, ok. I just mean that the only thing the plugin manager does in terms of installation is cloning to the plugins directory (as far as I could tell).
I'll get the full RC I had later. But the one I was using to minimally reproduce the issue is above.
@andreyorst How about passing the configuration to plug directly?
plug alexherbo2/auto-pairs.kak %{
hook global WinCreate .* auto-pairs-enable
map global user s -docstring 'Surround' ':<space>auto-pairs-surround<ret>'
}
That'd actually be really nice as a default since it lets you not worry about another level of quote escaping.
The config I was using was quite similar to what you just showed with the evaluate-commands
I'm just not at my laptop right now so I can't copy and paste the config I was using.
Yeah, I'm currently doing the implementation of it rightnow. Just was too busy with fzf.kak though. I'm leaving this topic in favor of https://github.com/andreyorst/plug.kak/issues/5 since the issue is more likely with the configuration, rather than with plug.kak
Here are the two config files I'm using:
colorscheme zenburn
add-highlighter global/ show-matching
source "%val{config}/plugins/plug.kak/rc/plug.kak"
plug "andreyorst/plug.kak"
plug "https://gitlab.com/Screwtapello/kakoune-cargo"
evaluate-commands %sh{
[ -z "${kak_opt_plug_loaded_plugins##*kakoune-cargo*}" ] || exit
echo "map -docstring \"Cargo commands\" global user <c> %{:enter-user-mode cargo<ret>}"
}
plug "https://github.com/alexherbo2/auto-pairs.kak"
evaluate-commands %sh{
[ -z "${kak_opt_plug_loaded_plugins##*auto-pairs.kak*}" ] || exit
echo "hook global WinCreate .* %{ auto-pairs-enable }"
echo "map global user s :auto-pairs-surround<ret>"
echo "map global user S ':auto-pairs-surround _ _ * *<ret>'"
}
source "%val{config}/rustrc"
And the rustrc at the bottom.
plug "https://gitlab.com/Screwtapello/kakoune-cargo"
evaluate-commands %sh{
[ -z "${kak_opt_plug_loaded_plugins##*kakoune-cargo*}" ] || exit
echo "map -docstring \"Cargo commands\" global user <c> %{:enter-user-mode cargo<ret>}"
}
hook global WinSetOption filetype=rust %{
# If rustfmt is available, let's set up formatting.
evaluate-commands %sh{
if command -v rustfmt >/dev/null 2>&1; then
printf "%s\n" "set-option window formatcmd rustfmt"
# If there's a config file here,
# let's do formatting by default.
if [ -f rustfmt.toml ]; then
printf "%s\n" "hook -group rust-auto-format window BufWritePre .* format"
else
printf "%s\n" "echo -debug %{rustfmt.toml not found}"
fi
else
printf "%s\n" "echo -debug %{rustfmt not available}"
fi
}
hook global WinSetOption filetype=(?!rust).* %{
remove-hooks window rust-auto-format
}
}
I installed the plugin manager using the exact commands in the plug.kak readme. Then when I loaded a Kakoune instance, I ran :plug-install
Same behavior observed after taking those steps.
@alexherbo2 It's still not fixed.
Again, adding "-draft" to the execute-keys statement in auto-pairs-insert-newline does fix the behavior of "o" and "O" as far as I can tell.
Can you try now? I've just pushed something that might fix it for you, if you are on macOS. We finally have working unit tests and they pass on Ubuntu and macOS with dash and bash as /bin/sh.
When autopairs is enabled, 'o' no longer moves the insert cursor to the beginning of the next line, instead it selects the current line and adds a new line below the insert point.
For example:
If I type:
ifoobar<Esc>obazfoo
appears instead of
Also, if inserting text when inside a pair, typing whitespace adds additional whitespace after the insert point.
So if I type:
I(foo bar baz bat<Esc>
(foo bar baz bat )
(only one space is showing up in the preformatted text, but there should be three spaces after bat)
appears instead of
(foo bar baz bat)
I kinda get what's happening with that, (the whitespace is one of the pair characters), but I think that should only happen if there aren't any non-whitespace characters between the already paired characters. That is, if I type a left paren, then a whitespace, the balance should be a whitespace, then a right paren. But if I type a left paren and then any non-whitespace character, the balance should only ever be a right paren.