^K cut line is really slow

[pkitszel]

^K cut line is really slow

Cutting line by CTRL+K is really slow, file was standard code file, I reproduced it in two different files. File had less than 450 lines before cutting. Other things (save, find) are working fine.

Specifications

Commit hash: c51f849 OS: Ubuntu 18.04 Terminal: urxvt (via X-Ming on Windows)

[Calinou]

How much time does it take to cut a line? (In other words, can you define what "really slow" is in this context?)

[pkitszel]

Thank you for your interest! It takes about 6 seconds (measured by stopwatch). So, orders of magnitude too slow.

[LevitatingBusinessMan]

It's instant for me, with pretty much any buffer size. I am curious what'd results you'd get when using this benchmarking system: https://github.com/zyedidia/micro/pull/1549

[sparques]

Do you have xclip installed? Are you using a remote X session?

[pkitszel]

@deusnefum - I don't have xclip installed, and it was over remote X session.

I could not reproduce issue on the same machine setup but local/standard X session.

[pkitszel]

@deusnefum , I reproduced the issue

now from linux host, ssh -X to another linux machine, xclip and xsel installed (removal of either of those has not changed the behavior)

I'm using 2.0.10 + two additional PRs merged: dmaluka/luamouse and dmaluka/hlsearch-v3

[matthew-hiles]

@pkitszel,

If you set 'set clipboard internal' does it prevent the lag?

[pkitszel]

@pkitszel,

If you set 'set clipboard internal' does it prevent the lag?

yes, then it's fast

[matthew-hiles]

Okay, so it definitely has to do with the lag communicating the X11 clipboard over the relatively slow SSH tunnel. Potentially fixable by making updates to the X11 clipboard asynchronous to the updates to the internal clipboard.

I'll see if I can't get a PR going--won't be happening today though.

[hholst80]

It is not specific to SSH. It is slow also on a native terminal in Sway.