Closed jkonecny12 closed 8 years ago
When I was deleting line in a file this happened again.
I have this in pstree
| |-tmux-+-bash---kak---sh---xsel
| | |-bash
| | |-bash---kak
| | |-bash-+-less
| | | `-sudo---pstree
| | `-bash---gdb---7*[{gdb}]
Based on this, it looks like there could be problem with my hook on saving clipboard:
# yank to system clipboard always
hook global NormalKey y|d|c %{ nop %sh{
echo "$kak_selection" | xsel --input
}}
But it worked without a problem for some time. Was there some changes recently in this behavior?
Not sure how xsel behaves, but if xsel is still running, Kakoune cant do much until it exits if you use a %sh{ ... }
block.
You might be able to fix the problem by using <a-|>
instead, that explicitely does not read the command output:
hook global NormalKey y|d|c %{ exec -draft <space><a-|>xsel<space>--input<ret> }
I'll try that. Thank you.
Not sure if this is the same bug but I have kakoune freezing when using xsel from a mapping. It doesn't respond to <C-c>
.
This occurs randomly when using this mapping:
decl str pastecmd %sh{ which pbpaste > /dev/null && echo 'pbpaste' || echo "'xsel --clipboard --input'" }
map global user p '!$kak_opt_pastecmd<ret>'
Some informations I gathered, hope this helps:
$ cat -e cmdline
xsel^@--clipboard^@--input^@%
(gdb) bt
#0 0x00007f6e9bb394d0 in __read_nocancel () from /usr/lib/libc.so.6
#1 0x00007f6e9c6d2a6e in _nc_wgetch () from /usr/lib/libncursesw.so.6
#2 0x00007f6e9c6d3225 in wgetch () from /usr/lib/libncursesw.so.6
#3 0x00000000004fc86d in Kakoune::NCursesUI::get_key() ()
#4 0x0000000000492322 in Kakoune::Client::handle_available_input(Kakoune::EventMode) ()
#5 0x00000000004fbc79 in ?? ()
#6 0x0000000000514602 in Kakoune::EventManager::handle_next_events(Kakoune::EventMode, __sigset_t*) ()
#7 0x000000000056192b in Kakoune::ShellManager::eval(Kakoune::StringView, Kakoune::Context const&, Kakoune::StringView, Kakoune::ShellManager::Flags, Kakoune::ShellContext const&) ()
#8 0x000000000053a0a9 in void Kakoune::insert_output<(Kakoune::InsertMode)0>(Kakoune::Context&, Kakoune::NormalParams)::{lambda(Kakoune::StringView, Kakoune::PromptEvent, Kakoune::Context&)#1}::operator()(Kakoune::StringView, Kakoune::PromptEvent, Kakoune::Context&) const ()
#9 0x0000000000511f8d in Kakoune::InputModes::Prompt::on_key(Kakoune::Key) ()
#10 0x00000000005039c6 in Kakoune::InputHandler::handle_key(Kakoune::Key) ()
#11 0x000000000052e23b in ?? ()
#12 0x00000000005070c1 in Kakoune::InputModes::NextKey::on_key(Kakoune::Key) ()
#13 0x00000000005039c6 in Kakoune::InputHandler::handle_key(Kakoune::Key) ()
#14 0x0000000000492103 in Kakoune::Client::handle_available_input(Kakoune::EventMode) ()
#15 0x00000000004fbc79 in ?? ()
#16 0x0000000000514602 in Kakoune::EventManager::handle_next_events(Kakoune::EventMode, __sigset_t*) ()
#17 0x0000000000523874 in run_server(Kakoune::StringView, Kakoune::StringView, bool, bool, bool, UIType, Kakoune::ArrayView<Kakoune::StringView const>, Kakoune::BufferCoord) ()
#18 0x0000000000460872 in main ()
Zero problem with pastecmd
set to xsel
.
Is that really how you declared the mapping, or is it just pseudo code?
frankly, that looks like a bug in xsel, or if not a bug, an unexpected behaviour. Kakoune wrote to a pipe connected to xsel stdin, then closed it, but in lsof seems stdin for xsel is now the terminal, which would suggest xsel reopened it itself. I think we'd need to explore xsel code to understand whats going on here, but its strange that this tool wont just read from stdin until closed, copy whatever came into the X11 clipboard and exit immediately.
Update after a few hours of usage, xsel
(without arguments) does the job perfectly. It really looks like --input
and --output
are inconstants, either by documentation or by behaviour. In short I don't think this is kakoune's fault, like @mawww says.
@lenormf this is the actual commands (extracted from my kakrc).
@casimir are you running on Wayland or Xorg? I've changed to Wayland recently so I'm thinking if that can be the issue here.
Awesome isn't compatible with Wayland but I don't have xorg-xserver installed. I guess I use XWayland.
I think we established this is not a Kakoune bug, but a strange behaviour of xsel. Reopen if there is something new.
This bug has some race condition, I can't reproduce it normally. I just got it 2 times in a few days. First it was when I edited
git commit
message and now in normal file edit.Here is the backtrace:
In the first case I did
killall kak
and when I run it again I was in the same situation. I tried it a few more times with the same result. However when I changed editor in git, edit, set it back to kakoune, it was fine again.