WSL + ConPTY + vim -> paste with blanks lines #2324
Comments
|
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 #2093. |
|
This isn't a dupe - this is different behaviour |
|
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 |
|
I can confirm this happens to me too on: WSL (Ubuntu 18.04 LTS) on Windows 10 Pro (version 10.0.17763) Includes blank lines: Expected behaviour: 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, Hyper applied a fix by replacing the line endings when the platform is win32. @chrisduerr Is this something that can be implemented in Alacritty? @jamessewell In the meanwhile, you can add |
|
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 ***@***.***> wrote:
This issue is described here,
vercel/hyper#654 <vercel/hyper#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
<#2324>,
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 That said, I'm not sure if this is a proper solution as the original text has |
This comment has been minimized.
This comment has been minimized.
|
In case anyone wants a hack to do this, here is my AutoHotKey script for changing ; 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 |
|
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: 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() |
On Windows, most copying-and-pasting will use CRLF vs. LF -- this means that pasting from Windows *into* Alacritty will likely end-up with duplicated newlines, as Alacritty will send *both* '\r' and '\n'. This change replaces "\r\n" with "\n" when pasting, such that these duplicated newlines do not appear. See: alacritty#2324 (comment)
|
For anyone interested, I implemented @BYK's suggestion here: Without this change, copy-and-pasting from Windows into Alacritty (e.g., into 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). |
On Windows, most copying-and-pasting will use CRLF vs. LF -- this means that pasting from Windows *into* Alacritty will likely end-up with duplicated newlines, as Alacritty will send *both* '\r' and '\n'. This change replaces "\r\n" with "\n" when pasting, such that these duplicated newlines do not appear. See: alacritty#2324 (comment)
On Windows, most copying-and-pasting will use CRLF vs. LF -- this means that pasting from Windows *into* Alacritty will likely end-up with duplicated newlines, as Alacritty will send *both* '\r' and '\n'. This change replaces "\r\n" with "\n" when pasting, such that these duplicated newlines do not appear. See: alacritty#2324 (comment)
|
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... |
|
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) |
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".
Maybe you're in luck: microsoft/terminal#376 (comment) |
|
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. |
Thanks for that, appreciated. I will try to build my own.
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 😄
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 selection: semantic_escape_chars: " \t/\"semantic_escape_chars: ",│`|:"' ()[]{}<>\t;=.\/@" mouse_bindings:
key_bindings:
shell: |
|
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 #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 (aytey@3b5a5fc). |
|
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 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 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 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 |
On Windows, most copying-and-pasting will use CRLF vs. LF -- this means that pasting from Windows *into* Alacritty will likely end-up with duplicated newlines, as Alacritty will send *both* '\r' and '\n'. This change replaces "\r\n" with "\n" when pasting, such that these duplicated newlines do not appear. See: alacritty#2324 (comment)
On Windows, most copying-and-pasting will use CRLF vs. LF -- this means that pasting from Windows *into* Alacritty will likely end-up with duplicated newlines, as Alacritty will send *both* '\r' and '\n'. This change replaces "\r\n" with "\n" when pasting, such that these duplicated newlines do not appear. See: alacritty#2324 (comment)
On Windows, most copying-and-pasting will use CRLF vs. LF -- this means that pasting from Windows *into* Alacritty will likely end-up with duplicated newlines, as Alacritty will send *both* '\r' and '\n'. This change replaces "\r\n" with "\n" when pasting, such that these duplicated newlines do not appear. See: alacritty#2324 (comment)
On Windows, most copying-and-pasting will use CRLF vs. LF -- this means that pasting from Windows *into* Alacritty will likely end-up with duplicated newlines, as Alacritty will send *both* '\r' and '\n'. This change replaces "\r\n" with "\n" when pasting, such that these duplicated newlines do not appear. See: alacritty#2324 (comment)
On Windows, most copying-and-pasting will use CRLF vs. LF -- this means that pasting from Windows *into* Alacritty will likely end-up with duplicated newlines, as Alacritty will send *both* '\r' and '\n'. This change replaces "\r\n" with "\n" when pasting, such that these duplicated newlines do not appear. See: alacritty#2324 (comment)
|
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 🥳 |
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! |
On Windows, most copying-and-pasting will use CRLF vs. LF -- this means that pasting from Windows *into* Alacritty will likely end-up with duplicated newlines, as Alacritty will send *both* '\r' and '\n'. This change replaces "\r\n" with "\n" when pasting, such that these duplicated newlines do not appear. See: alacritty#2324 (comment)
On Windows, most copying-and-pasting will use CRLF vs. LF -- this means that pasting from Windows *into* Alacritty will likely end-up with duplicated newlines, as Alacritty will send *both* '\r' and '\n'. This change replaces "\r\n" with "\n" when pasting, such that these duplicated newlines do not appear. See: alacritty#2324 (comment)
On Windows, most copying-and-pasting will use CRLF vs. LF -- this means that pasting from Windows *into* Alacritty will likely end-up with duplicated newlines, as Alacritty will send *both* '\r' and '\n'. This change replaces "\r\n" with "\n" when pasting, such that these duplicated newlines do not appear. See: alacritty#2324 (comment)
|
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... |
|
As a WSL2 user considering migrating from Windows Terminal to Alacritty, I was also hit by this issue and initially surprised, because I've not seen this in WT (albeit similar problems when trying to get stuff from vim into the clipboard).
This is how I set up my vimrc to have a function copy and paste from WLS + Alacritty and the Windows Host, maybe it helps others: " clipboard
vnoremap <leader>y :w !clip.exe<CR><CR>
nnoremap <leader>p :r!pbpaste<CR>'.kJ
#!/bin/bash
powershell.exe Get-Clipboard | sed 's/\r$//' | sed -z '$ s/\n$//'
exit 0 |
|
Here is my AutoHotKey v2 script. |
This is a nice workaround, thank you! I had to make some changes to get it working:
window:
title: alacritty
dynamic_title: false
#Requires AutoHotkey v2
#HotIf WinActive("alacritty")
^+v::
{
A_Clipboard := StrReplace(A_Clipboard, "`r`n", "`n")
Send("^+v")
}
return
#HotIfThis way, you can be sure that your AHK script will always target alacritty no matter what process is running. I'm sure you could probably make it a little more robust than I did, but this got it working reliably for me. |
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.
Will become
When pasted into vim. Pasting directly into the shell or nano works correctly.
This is not an issue from Hyper, PuTTY etc...
The text was updated successfully, but these errors were encountered: