Windows 10 1809 + alacritty 0.3.0

When using ConPTY and bash as my shell I get issues when copying multi line text from Windows -> alacritty.

# Windows 10 ConPTY backend (Windows only)
#
# This will enable better color support and may resolve other issues,
# however this API and its implementation is still young and so is
# disabled by default, as stability may not be as good as the winpty
# backend.

Will become

# Windows 10 ConPTY backend (Windows only)

#

# This will enable better color support and may resolve other issues,

# however this API and its implementation is still young and so is

# disabled by default, as stability may not be as good as the winpty

# backend.

When pasted into vim. Pasting directly into the shell or nano works correctly.

This is not an issue from Hyper, PuTTY etc...

Strangely this works correctly when I SSH to some systems, I've tried cloning the vim settings from them, but it seems to be something else.

It also starts working when I turn off ConPTY support.

It looks like it has something to with Windows line ending. Copying the text from notepad++ with windows line endings shows extra new lines, but copying from notepad++ with linux line endings does not add extra new lines. No idea if this is vim's doing or alacritty though.

This seems to be a duplicate of https://github.com/jwilm/alacritty/issues/2093.

This isn't a dupe - this is different behaviour

@chrisduerr

I don't think we accept newlines as characters now that I think about it, so all newlines are interpreted as manual line breaks. Will re-open and investigate tomorrow.

The strange thing that this works fine inside tmux (which is a good workaround, using -c tmux as an arg to bash from the config file) - so it must be a fixable issue.

I can confirm this happens to me too on:

WSL (Ubuntu 18.04 LTS) on Windows 10 Pro (version 10.0.17763) Alacritty 0.3.2 (shell: bash.exe and ConPTY) tmux 2.6-3ubuntu0.1 (default 18.04 package)

Includes blank lines: neovim 0.3.4 (inside tmux or not) vim 8.0.1453 (native shell)

Expected behaviour: vim 8.0.1453 (inside tmux)

If you'd like further version or combination testing I am happy to do so!

Looking into this again, it's definitely not a duplicate, however since this works great on Linux my assumption would still be that Windows is doing something stupid here.

I'd assume this should be easy to fix, I feel like this might just be an issue with line endings in Windows vs Linux (so /r and /n might both act as newlines and that's why we got two?), or Windows just having double line endings.

This issue is described here, https://github.com/zeit/hyper/issues/654

Hyper applied a fix by replacing the line endings when the platform is win32. https://github.com/zeit/hyper/blob/6a05b7307c6b4b9de36ead754be735b0b9748c65/app/config/import.js#L9

@chrisduerr Is this something that can be implemented in Alacritty?

@jamessewell In the meanwhile, you can add set ff=unix to your vimrc to replace the line endings automatically until it's fixed in Alacritty (if possible)

Hi,

set ff=unix does not seem to work for me - I still get blank lines.

Cheers, JS

On Wed, Jun 19, 2019 at 11:05 AM JDTX [email protected] wrote:

This issue is described here, zeit/hyper#654 https://github.com/zeit/hyper/issues/654

Hyper applied a fix by replacing the line endings when the platform is win32.

https://github.com/zeit/hyper/blob/6a05b7307c6b4b9de36ead754be735b0b9748c65/app/config/import.js#L9

@chrisduerr https://github.com/chrisduerr Is this something that can be implemented in Alacritty?

@jamessewell https://github.com/jamessewell In the meanwhile, you can add set ff=unix to your vimrc to replace the line endings automatically until it's fixed in Alacritty (if possible)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jwilm/alacritty/issues/2324?email_source=notifications&email_token=AAJJDI32NZQYZTDWEFB6OS3P3GA45A5CNFSM4HGZAUM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYAMDHI#issuecomment-503366045, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJJDI2DF4HV5ZI4N66RLHTP3GA45ANCNFSM4HGZAUMQ .

@jamessewell I installed WSL/Ubuntu on my local machine and was able to replicate your issue and fix it by setting the term to builtin_ansi.

:set term=builtin_ansi

Give that a try in your vimrc, worked fine on my end.

The "solution" seems to be adding .replace("\r\n", "\n") to this line: https://github.com/jwilm/alacritty/blob/a23b372f34c58710678b888addcda2e3b7d45111/alacritty_terminal/src/input.rs#L351

That said, I'm not sure if this is a proper solution as the original text has CRLF in it and not sure if it is the terminal emulator's job to normalize that. Thoughts? If people think this is a good solution, I'll submit a PR w/ tests.

I'm experiencing a similar issue, though I'm not using WSL. For me Firefox is involved:

• copying from alacritty, pasting into alacritty: works as expected
• copying from Firefox, pasting into alacritty (either into vim or just into zsh): additional newlines appear
• copying from LibreOffice Writer, pasting into alacritty: works as expected

System: Gentoo, kernel 5.2.7 sway 1.2 wlroots 0.7.0 wl-clipboard 1.0.0 alacritty from master (--version: 0.3.3 (f6f444b)) Firefox nightly, so ~71.0, running in native wayland mode

If more info is needed, or if I need to open a separate issue for this one, please let me know.

@DRiKE https://github.com/jwilm/alacritty/issues/2844

In case anyone wants a hack to do this, here is my AutoHotKey script for changing \r\n to \n when pasting to alacritty

; For window with name "Alacritty" 
; To make window name persistent, change window.name property in alacritty.yml
; And set dynamic_title=false
#IfWinActive Alacritty

; Ctrl+Shift+V -- change line endings
^+v::
    ClipboardBackup := Clipboard                        ; To restore clipboard contents after paste
    FixString := StrReplace(Clipboard, "`r`n", "`n")    ; Change endings
    Clipboard := FixString                              ; Set to clipboard
    Send ^+v                                            ; Paste text
    Clipboard := ClipboardBackup                        ; Restore clipboard that has windows endings
    return

#IfWinActive

@meandmymind Thanks! For anyone else reading, if you want to still use dynamic titles, you can use the following #IfWinActive guard instead:

#IfWinActive, ahk_exe alacritty.exe

I had the same issue for a while so I wrote a little vim script. It also covers some edge cases I encountered and it fits for my workflow, in case someone is interested

Revisions will be tracked here: https://gist.github.com/saisasidhar/a2b627b84c057f469a0e8868841f88f5

Had some fun learning about vim and vim scripting ;)

Script:

" Paste text from alacritty (windows) into vim without additional blanklines
" Issue: https://github.com/alacritty/alacritty/issues/2324
" 
" Place this vim file in a plugin directory of vim. Example: $HOME/.vim/plugin/alapasty.vim
" Type `:Ap<Cr>` to open up a buffer in insert mode. Use `Shift+Insert` to copy text into this buffer. 
" Press <Esc> and the text will be formatted and placed in the originating buffer
"
" Note: This plugin takes care of some common edge-cases when working with code. Make sure the first few lines are
" either blank (just line endings is okay) or it has the first line of the content you want to paste. 
" This is critical because the script uses "%normal jdd" to dispatch repetitive jump and delete motions over the entire file.
"
" Author: Sai Sasidhar Maddali <github.com/saisasidhar>
" 
if exists('alapasty') || &cp
  finish
endif
let alapasty=1

let AlapastyBufferName = ".alapasty"

function! s:AlapastyCreate()
  let bufn = bufnr(g:AlapastyBufferName)
  if bufn == -1
    exe "new " . g:AlapastyBufferName
  else
    exe "split +buffer" . bufn
  endif
  exe ":%d"
  set paste
  exe "startinsert"
endfunction

function! s:AlapastyManipulate()
  " count empty lines in the beginning of the buffer
  let ls = line('$')
  let ix = 1
  while ls >= ix
    let line = getbufline('$', ix)
    if len(line[0]) != 0
      break
    endif
    let ix += 1
  endwhile

  " remove empty lines
  normal! gg
  while ix > 1
    exe ":0d"
    let ix -= 1
  endwhile

  " skip formatting and pasting if it does not make any sense (default line feed for an empty buffer)
  if line('$') == 1
    let line = getbufline('$', ix)
    if len(line[0]) == 0
      exe "hide"
      return
    endif
  endif

  " jump every other line and delete it
  exe "%normal jdd"
  normal! Gygg
  exe "hide"
  normal! p
endfunction

function! s:AlapastySetProps()
  setlocal buftype=nofile
  setlocal bufhidden=hide
  setlocal noswapfile
  setlocal buflisted
endfunction

autocmd BufNewFile .alapasty call s:AlapastySetProps()
autocmd InsertLeave .alapasty call s:AlapastyManipulate()
command! Ap call s:AlapastyCreate()

For anyone interested, I implemented @BYK's suggestion here:

• https://github.com/andrewvaughanj/alacritty/commit/8d2d1eb780ed7b24004c9595595cc83aa131c795
• https://github.com/andrewvaughanj/alacritty/tree/windows_paste_crlf

Without this change, copy-and-pasting from Windows into Alacritty (e.g., into vim) would have these duplicated newlines.

This simple fix indeed removes these (I agree it would be nice for the terminal not to interfere in this way, but this helps me remain productive while using Alacritty).

Are you guys going to merge a fix for this in? It would definitely help windows users (such as myself), and other terminal emulators like mintty are handling this correctly already.

It's pretty annoying; now whenever I paste something into my terminal window, I need to do some "post-processing" to remove every second blank line...

@andrewvaughanj That change of yours looks promising, why don't just raise a PR for it? Hopefully the maintainers will merge it in then.

100% my changes are not going to be integrated; they work-around bugs in ConPTY that are "not interesting" to Alacritty (there's no criticism here; Alacritty as a project is welcome to be uninterested in work-arounds for bugs in third-party libraries).

Well, sad to hear that. That's an interesting viewpoint; ultimately, you need to make things work for the user as they expect them to (like mintty does). If that means applying whatever hack/workaround is necessary, then so be it. But that's my view of the world. Anyway, thanks for reply.

So out of interest, what is the Alacritty devs' message to Windows users on this issue? Don't use Alacritty? :) I guess that's probably one of the answers if you're unwilling to implement workarounds for problems...

If you spend enough time reading the issue track for Alacritty, it becomes quite clear that the project "is not interested" in supporting users that fall outside of their desired use-case:

• "Not my job to fix Windows" -- https://github.com/alacritty/alacritty/issues/5015#issuecomment-827918322

• "Just ask Microsoft to fix this or avoid using an operating system that doesn't want to be used" -- https://github.com/alacritty/alacritty/issues/4993#issuecomment-824214331

• "you can send that complaint to Microsoft" -- https://github.com/alacritty/alacritty/issues/4794#issuecomment-779134026

• "Can you reproduce this on Linux? This sounds like yet another issue with ConPTY" -- https://github.com/alacritty/alacritty/issues/4759#issuecomment-772793947

And then you'll see posts that straight-up say "use another terminal"/"don't use Alacritty".

Honestly, I'm happy that Alacritty works at all on Windows, and that with a few personal patches, I can make it be perfectly productive for me.

Don't use Alacritty? :) I guess that's probably one of the answers if you're unwilling to implement workarounds for problems...

I think we have the answer to that ...

I'm not trying to shame @chrisduerr here, but just so everyone is fully aware, my post immediately above is liked by Chris -- this might "as good" of a confirmation of the "not interested" position as you're going to get.

I believe that Alacritty will fix genuine bugs that are due to Alacritty itself; however, if they are "compatibility issues" that only exist due to Windows doing something different/wrong/weirdly from how a Linux PTY works, and fixing this in Alacritty "degrades" the cleanliness of Alacritty code base, then you're probably out of luck if you expect project-level support.

Understand the part that they don't care about Windows; I have some apps that I developed in a cross-platform manner, and while I could make them work on Linux besides Windows and OS X, I don't care either :)

What I found a bit weird is that you came up with a patch, right, and you said it's simple. So it would only need merging to make the lives of people on Windows easier. I get the clean code base argument somewhat, but if it's a simple patch, who cares really... I get it that they don't want to rearchitect the codebase just for Windows' ske, but if it's a simple patch, it doesn't hurt anybody, does it? Just add a Windows-only config parameter for it and job done.

Anyway, IMHO, as a Windows user, etc. :)

(I don't get even started on the non-existent mouse support for Windows, I'm sure it will fall on deaf ears... :P)

who cares really

The maintainers who need to look after the code-base forever more and might not have the ability/inclination to test/run on Windows.

Honestly, the "easiest" way is probably just to build from source based off of https://github.com/andrewvaughanj/alacritty/tree/avj_win_merge, which is master + my Windows patches, and then not worry about this being a "Windows-specific fork".

(I don't get even started on the non-existent mouse support for Windows, I'm sure it will fall on deaf ears... :P)

Maybe you're in luck: https://github.com/microsoft/terminal/issues/376#issuecomment-849756080

Is there an upstream ConPTY that could be linked to this issue?

I believe ConPTY isn't "buggy", it just isn't a Linux PTY. The maintainers of Alacritty don't want to put in custom code specifically to deal with nuances of ConPTY vs. how a PTY normally works under Linux. At least, this is my belief.

Honestly, the "easiest" way is probably just to build from source based off of https://github.com/andrewvaughanj/alacritty/tree/avj_win_merge, which is master + my Windows patches, and then not worry about this being a "Windows-specific fork".

Thanks for that, appreciated. I will try to build my own.

The maintainers who need to look after the code-base forever more and might not have the ability/inclination to test/run on Windows.

Well, your patch is like less than 5 lines or so? With additional config handling it would be maybe 15 lines? So, please, come on... 😄 If it breaks, someone who cares about Windows will submit a new patch, merge, job done.

What bugs me, and where I see the discrepancy, is that they're providing Windows builds, they claim Alacritty runs on Windows, BUT at the same time they refuse to merge in very clean 5 line patches that would make the lives of Windows folk a LOT easier. Does that makes any sense? If you provide Windows builds, you want Windows people to use your app, no? Or maybe not... and this where I find this attitude confusing.

It doesn't make a whole lot of rational sense to me, so I just chalk it up as a case of ideological hardheadedness and/or emotional response against Windows or something. But alright, everybody is the king of their codebase... 😁

Btw, surely someone from their team must test the Windows builds before putting out a release? Well, I hope so 😄 Hell, if that's the problem, I'm sure yourself or I would be happy to give every Windows release a little test before it becomes official.

(I don't get even started on the non-existent mouse support for Windows, I'm sure it will fall on deaf ears... :P)

Maybe you're in luck: microsoft/terminal#376 (comment)

That sounds promising, cheers!

Btw, thanks @chrisduerr and co. for the great FREE app. I enjoy using it and don't take my comments as hostile; I just wanted to point out some things that don't make a whole lot of logical sense to me 😄

I think with a very little extra effort you would gain a lot more Windows users. Surely pasting into the terminal is a very common operation, so everybody on Windows would be most likely put-off by the incorrect (from the user's perspective) paste behaviour, and potentially migrate to a different terminal. So your call, I guess 😄

Peace!

First I would like to say thank you for an amazing app.

I've faced this randomly over the past couple of weeks and just discovered a trivial way to get rid of the extra new lines. Just run tmux and pasting would work normally

I'm using tmux, and Vim under tmux has the same issue.

I'm also using Vim under tmux, it could be something in my configuration so I'm sharing here.

Tested without tmux and got the extra line breaks, but with tmux it works like a charm. Hope this works for you

unbind C-b
#set-option -g prefix `
set-option -g prefix C-]

# reload config file
bind -n F5 source-file ~/.tmux.conf

set -s escape-time 0

# switch panes using Alt-arrow without prefix
bind -n S-Left select-pane -L
bind -n S-Right select-pane -R
bind -n S-Up select-pane -U
bind -n S-Down select-pane -D

bind-key -n F2 new-window
bind-key -n M-Left previous-window
bind-key -n M-Right next-window
bind-key -n M-S-Left swap-window -t -1\; select-window -t -1
bind-key -n M-S-Right swap-window -t +1\; select-window -t +1

bind -n F3 run-shell 'tmux set-environment -g SSH_HOST #{window_name}' \; \
        new-window 'lftp -e "cd" sftp://$SSH_HOST'

# Not supported in alacritty, waiting for windows to fix
# Works with WezTerm
# Too much trouble for what its worth, disabling but keeping
set -g mouse off

# Paste Windows clipboard using middle mouse button, Disabled
#bind-key -n MouseDown2Pane run "tmux set-buffer \"$(powershell.exe -command Get-Clipboard | sed 's/\r//g')\"" \; paste-buffer

### Theme
###########################################################################

# Statusbar Color Palatte
set-option -g status-justify left
set-option -g status-bg black
set-option -g status-fg white
set-option -g status-left-length 40
set-option -g status-right-length 80

# Pane Border Color Palette
set-option -g pane-active-border-style fg=green,bg=black
set-option -g pane-border-style fg=white,bg=black
#set-option -g pane-active-border-fg green
#set-option -g pane-active-border-bg black
#set-option -g pane-border-fg white
#set-option -g pane-border-bg black

# Message Color Palette
set-option -g message-style fg=black,bg=green

# Window Status Color Palette
setw -g window-status-style bg=black,fg=white
setw -g window-status-current-style bg=black,fg=green
#setw -g window-status-bg black
#setw -g window-status-current-fg green
#setw -g window-status-bell-attr default
#setw -g window-status-bell-fg red
#setw -g window-status-activity-attr default
#setw -g window-status-activity-fg yellow

### UI
###########################################################################

# Notification
setw -g monitor-activity on
set -g visual-activity on
set-option -g bell-action any
set-option -g visual-bell off

# Automatically set window titles
set-option -g set-titles on
#set-option -g set-titles-string '#H:#S.#I.#P #W #T' # window number,program name,active (or not)

# Statusbar Adjustments
set -g status-left " #[default]"

# Show performance counters in statusbar
# Requires https://github.com/thewtex/tmux-mem-cpu-load/
set -g status-interval 4
set -g status-right "#[fg=cyan]%H:%M #[default]"

### Plugins
###########################################################################
set -g @plugin 'tmux-plugins/tpm'
set -g @plugin 'tmux-plugins/tmux-yank'```

selection:

semantic_escape_chars: " \t/\"

semantic_escape_chars: ",│`|:"' ()[]{}<>\t;=.\/@" save_to_clipboard: true

mouse_bindings:

• { mouse: Middle, action: PasteSelection }

key_bindings:

• { key: Q, mods: Shift|Control, action: Quit }
• { key: N, mods: Control, action: SpawnNewInstance }

shell: program: wsl ~

I don't think this is a conpty bug, the windows terminal does not have the issue. However, Alacritty with the latest OpenConsole.exe using https://github.com/alacritty/alacritty/pull/4501, still has the issue.

I'm not sure if it works better or not, but I have personally not seen this bug or any other Windows showstoppers for that matter, since I started using OpenConsole a year ago. But that's probably because Neovim seems to be handling multiline pasting just fine.

@fredizzimo I have no idea about Windows Terminal, but a number of other terminals that use ConPTY actually do this stripping for you before you paste, to ensure some kind of consistency between Windows and your shell.

However, this isn't a work-around that Alacritty (via @chrisduerr) wishes to implement because it isn't the terminal's job to "interfere" with your content (which I think is totally reasonable).

If this is make-or-break for you, you can just build Alacritty from source with that change implemented (https://github.com/andrewvaughanj/alacritty/commit/3b5a5fcaa76041a772e064cf74130c867ef5abe3).

Yes, the windows terminal strips the carriage return characters., see here https://github.com/microsoft/terminal/blob/ed87689c048e7d41ff28684d171f77ba9cb579f2/src/interactivity/win32/Clipboard.cpp#L147. And I think it does it even when the target is cmd or powershell, at least I don't see any special handling for them, which indicates that both of them can handle line feeds just fine.

But it's definitely a job for the terminal emulator to handle IMO. ConPty, definitely can't do it, since it just sees a stream of characters, it knows nothing about copy/pasting, so doing it there would break all sort of things, especially binary streams.

On the ideal level I can agree with that the terminal emulator should not mess with the input, but in practice it has to correctly work for the majority of the use cases. For example most editors can deal with pasting LF and automatically convert to CRLF, when you are editing a text document with windows line endings. While for example the shell itself might not handle CRLF correctly. So the LF format seems much more sensible.

Furthermore the Windows Terminal is going to be officially integrated into Windows 11, so I would say that Alacritty should follow the behaviour of that.

And finally for rich clipboard integration, there are things like win32yank.exe , which for example Neovim can use, and can optionally convert the line endings. The windows built in clip.exe, or the powershell clipboard could also be used.

Of course Alacritty could provide an option to disable or enable the behaviour, or even better have different shortcuts for normalized and unnormalized paste.

But no, it's not a make-or-break for me, since I haven't even noticed the issue until stumbling on it here. But probably because I don't use tools that don't handle CRLF. I also mostly use win32yank.exe through zsh for my terminal copy pasting. Also Interestingly the zsh shell does not have any problems dealing with the output of win32yank even when it's in the CRLF format. I double checked that it indeed retained the format by redirecting to a file and checking that.

Since alacritty 0.10.0 has been released and @andrewvaughanj hasn't updated his fork, I've created one and used the same fix against the v0.10.0 code, with a prebuilt binary for Windows.

PM me if release needs updating in the future

Wow, amazing that you can do releases 🥳

Wow, amazing that you can do releases 🥳

Yes that's a cool thing though it seems a bit unsafe to download an exe from a random fork 😅

Did it mostly for myself since I jump computers a lot but if it can be of use to somebody else that's great

Yeah, but it is likely to be a lot easier (for other people) than building their own version of Alacritty locally.

Seriously, good work!

Any progress on this ? I was very happy that copy and paste is ( system clipboard ) working with alacritty on windows. As a workaround I do use linux in encoding ( unix LF ) inside notepad++ .

Any progress on this ? I was very happy that copy and paste is ( system clipboard ) working with alacritty on windows. As a workaround I do use linux in encoding ( unix LF ) inside notepad++ .

Just use wsltty instead, as that's specifically made for Windows and has zero issues with copy/pasting. Alacritty devs seems to be completely uninterested in providing a good user-experience for Windows users, so time to move on...