alacritty: Wrapped text in VIM is copied with line break

I copied following wrapped line, but actually 1 line in VIM 8.2 as following image, by Ctrl+Shift+C on Alacritty, then paste the text to another terminal Alacritty or app by paste Ctrl+Shift+V.

Alacritty alacritty

Then I see the pasted text includes a line break like this with 2 lines. But I expected it is pasted as 1 line.


When using terminator (terminator 2.1.1) with the following image, this doesn’t happen. The pasted line is one line like below. Is it a known issue? How can I change this behavior? If you like, I can share my Alacritty and Terminator config files.

Terminator terminator



OS: Linux, Fedora 35 Version: alacritty 0.9.0 Linux/BSD: X11 i3 window manager. VIM version: 8.2

$ vim --version | head -1
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Dec 07 2021 00:00:00)


Crashes: STDERR, STDOUT : It’s not crash. Font/Terminal size: alacritty -vv Keyboard and bindings: alacritty --print-events

alacritty -vv

[2022-02-04 11:32:43.662712040] [DEBUG] [alacritty_terminal] New num_cols is 25 and num_lines is 27
[2022-02-04 11:32:43.662842174] [INFO ] [alacritty] Padding: 2 x 2
[2022-02-04 11:32:43.662887388] [INFO ] [alacritty] Width: 236, Height: 493
[2022-02-04 11:36:27.593113893] [DEBUG] [alacritty_terminal] [unhandled hook] params=[0], ints: [], ignore: false, action: 'z'
[2022-02-04 11:36:27.593153243] [DEBUG] [alacritty_terminal] [unhandled put] byte=122
[2022-02-04 11:36:27.593166045] [DEBUG] [alacritty_terminal] [unhandled unhook]
[2022-02-04 11:36:27.593177788] [DEBUG] [alacritty_terminal] [Unhandled CSI] action='m', params=[0], intermediates=[37]

alacritty --print-events

Too many logs. If you know how to filter only necessary logs in this case, please let me know.

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Reactions: 3
  • Comments: 17 (6 by maintainers)

Most upvoted comments

As a workaround, using set ttyfast solves the problem for Alacritty and Vim 9.0 (and also for the st terminal emulator).

Filed a bug as

I tried using TERM=xterm-256color and it works as expected (like other terminal emulators).

xterm seem like a conservative choice (neither sure about side-effects) so it’s OK with me.

Exactly the same happens to me (Version 0.11.0)

Oh not yet. Let me try it.