Closed ameliabradley closed 7 months ago
Still happening for me with 0.3.2. Tested on Fedora Linux with Konsole and Xterm.
How to reproduce:
[[snippets]]
description = "just for testing"
command = "echo '<name>'"
output = ""
echo 123456789012345678901234567890 | xclip
pet exec
or pet search
and paste the string in name
.
$ pet search
echo '1234567890123456789 0 1 23 4 5 6 7 8 9 0'
still happens on macOS Mojave; using pet version 0.3.2 and iTerm2 3.2.9
Still happening for me for v0.3.5 @knqyf263 can you please reopen?
At the time I fixed this, there were no such thing as go modules, but we were using the 2017 version of gocui. The suggested fix at the time was to disable Wrap (which is what we did). We are now at latest. Apparently there was a regression, because Wrap is still disabled.
You can see from this conversation here that the base gocui bug is still unfixed three years later.
Maybe it would be worth moving to a library other than gocui? Termui might be a viable option.
@NickLarsenNZ Thank you for the report. I reopened this issue.
@leebradley Hmm... can we fix this issue using gocui? If impossible, we should consider using Termui (Thank you for the good advice).
Sadly, this problem makes using of variables literally impossible 😖
Was literally the first thing i ran into (pasting a commit reference into the field), sods law ey?
Is this moving towards a fix? Or likely to be in limbo for 'a while'?
Not sure anyone has seen it,
https://github.com/jroimartin/gocui/issues/94#issuecomment-514247051
But theres a community fork of jroimartin/gocui that may be worth using instead if the original repo is unlikely to see a fix.
Can confirm it still happens. Will add it to high prio bugs
Copy+paste of a long value will insert spaces into the end result.
It's problematic when I have placeholders for URLs or something else that's a long string.