DeveloperProductivity
Post #7113 · source on Telegram
Goku Demonstrates the Cautious Approach to Copy-Paste Operations
Description
A two-panel Dragon Ball Z meme with the header 'It doesn't hurt to be cautious'. Top panel shows Goku in a focused prayer-like pose with text 'CTRL+C CTRL+V' representing a normal copy-paste. Bottom panel shows Goku looking more intense with a knowing finger raised, alongside text 'CTRL+C+C+C+C+C CTRL+V' representing the paranoid habit of pressing Ctrl+C multiple times to make absolutely sure something is copied before pasting. This captures the universal developer anxiety of not trusting the clipboard
Use J and K for navigation
Comments
75Comment deleted
The clipboard has a 100% success rate on Ctrl+C, but my trust issues from that one time it didn't paste correctly have a TTL of infinity
I don't just hit CTRL+C multiple times; I'm sending a packet burst to the clipboard manager to establish a quorum and ensure data replication before the paste commit
If only our eventual-consistency databases synchronized as faithfully as we hammer CTRL+C before every remote ‘ssh’ paste
After 20 years in the industry, I still don't trust the clipboard API more than I trust a junior's 'minor refactor' on a Friday afternoon - at least with the refactor, git blame tells me who to haunt
After 20 years in the industry, I've learned that pressing CTRL+C five times doesn't actually make the clipboard more reliable - but I still do it anyway, because the one time I didn't, I lost a perfectly crafted regex that took me 45 minutes to write. It's not paranoia if the clipboard has actually betrayed you before
Years of prod shells teach you to treat paste like a two-phase commit - spam SIGINT until the prompt is consistent, then apply
My clipboard uses at-least-once delivery - mash CTRL+C until quorum, then paste; just don’t run leader election in a prod shell where SIGINT is exactly-once
Triple CTRL+C: because clipboards suffer eventual consistency too
Am I the only one who has noticed that control C just sometimes straight up doesn't fucking work Comment deleted
Yes since fucking Clipboard history in build 18XXX was added Comment deleted
That can be disabled though, and I still run into this issue on an embedded version of Windows where the clipboard history is disabled Comment deleted
Yea but it probably had some internal change in the clipboard pipeline and its got ruined for all Comment deleted
No one mentions the chaotic Linux clipboard Comment deleted
Oh no, tell us now I am curious Comment deleted
It just sucks Comment deleted
works for me Comment deleted
I should get a clipboard manager at some point tho 🤔 Comment deleted
You are evil Comment deleted
meow? Comment deleted
"Works on my machine" from a random spectator is literally the worst thing you could have done 😂 Comment deleted
what can I say. perhaps their unreliable clipboard is a skill issue Comment deleted
Same was happening with me since at least El Capitan on MacOS Comment deleted
That's because you're supposed to press Command + C, you silly. Comment deleted
Like I don't know if it's specifically a thing that has started since Windows 10, but there is definitely some weird shit going on with trying to copy stuff sometimes Comment deleted
it's the windows clipboard, appeared in win 10. Google will know more Comment deleted
I faced similar issue while using Firefox in Windows 7 several years ago: in some circumstances at least the keyboard shortcut for copying didn't work (don't remember whether the menu item worked either). Perhaps that was just a big that was fixed several major releases later, as I don't remember facing it recentrly (and I still use Windows 7 btw 🤓). Comment deleted
This is genuinely a learned behaviour if you think about it I think the main reason is the fact that a) we know the action is repeatable without consequences b) there is no visual indication that something was succesfully copied c) sometimes copying actually doesn't copy for reasons unknown (focus? dropping inputs?) Comment deleted
Like, some developer's shit code actually made us distrust the shortcut until the end of time, and it may only have been a single case of it not working in a specific program Comment deleted
As we say in Russia: "copy seven times, paste once" Comment deleted
I've just never thought about why I actually mashed ctrl+c before now Comment deleted
Because Windows 10 has gaslit us into thinking we must have fucked up pressing the hotkey for pasting to fail Comment deleted
"+yy "+p Comment deleted
I can only assume it's poorly or improperly implemented Comment deleted
Exactly Comment deleted
There is 2 clipboards since Windows 8. Literally there is one for WinRT and for Win32 Comment deleted
Hmm... I don't remember what version I have to use for work. Guess I'm checking that in 5 hours. Comment deleted
And I think when they implemented the online syncing and history it got fucked because now the plain win32 clipboard also has async pipeline Comment deleted
Oh it's definitely the async pipeline Comment deleted
From what I figured is you go to copy, it takes an unknown number of ticks before it will actually hit the clipboard, and if you try to paste before it finishes then it just never hits the clipboard because the async will fail Comment deleted
Yeah 100% Comment deleted
Makes no sense to me why there's a race condition there Comment deleted
Because there is 2 clipboards that have to get syncronized and there is the online clipboard thing too Comment deleted
Windows internal API bullshit at work again Comment deleted
Win32 Clipboard api is not async btw Comment deleted
Fr Comment deleted
And then there is the old mail app that is winrt and clears the clipboard if it wrote to it and you close it. "Security" Comment deleted
I don't think most things were back then Comment deleted
This issue all started when they started trying to implement react into the operating system FOR SOME GOD FORSAKEN REASON Comment deleted
This is actually unrelated Comment deleted
Probably, it's just the timing of it all is roughly the same Comment deleted
Yeah true, I know WinRT with sync on its own works well because I used WinRT only Windows before and it worked reliably as fuck but on desktop windows where 90% of apps you use is win32 doesn’t work is ridiculous Comment deleted
By the way, totally unrelated, but fuck yeah NGNL Comment deleted
Probably just a compatibility layer thing then. Windows 12/13 will maybe save us? Comment deleted
I said this before I gave it enough thought and remembered that they're trying to push windows as a service, so... They need to get their API versioning shit together, and I have no evidence to believe they have even started attempting to do that Comment deleted
They did this with uwp/winrt but nobody liked to develop for that api Comment deleted
The thing is Microsoft tries to replace win32 by winrt so win32 is the compatibility layer now 💀 Comment deleted
Kind of figured the whole reason they would deprecate an API like that is because they would remove it in a future release. I don't know why we still have this ancient architecture floating around programs that are clearly breaking on the new versions. Comment deleted
Because people dont like change and developers are lazy to learn how AppContainers work Comment deleted
They're so afraid of making breaking changes that it's detrimental to the end user. If anything they should adopt versioned APIs instead of a single unified one with multiple layers of compatibility gumming it all up. Comment deleted
Yes winrt has that Comment deleted
Look up onecore api set Comment deleted
This happens with literally every single thing Microsoft touches though. I lost track how many instances of "new" and "old" outlook and teams programs they pushed, or O365 shenanigans Comment deleted
I noticed ctrl+c not working too. Just like the print screen key, unless i click the task bar first Comment deleted
Since we're talking about it, I think this whole issue came from efforts to get rid of the white (hung) application windows that happened since at least XP when an application is thought to not be responding by the operating system. It used to be that applications would act like they're not responding while they're still loading If you try to interact with them too quickly during that process, it would cause it to hitch and interrupt (and push that interrupt to the end of the priority stack) until the CPU would eventually try and go back to it later. Comment deleted
They were not white untill Windows Vista or 7 Comment deleted
Vista, that was it Comment deleted
I swear to God if I could just have a few months at Microsoft... Comment deleted
We literally need windows 10 X Comment deleted
Win32 apps run in a VM like on Xbox Comment deleted
Because nobody uses Linux Comment deleted
😆 Comment deleted
The vocal minority can boo me all they want but I'm still right Comment deleted
just using y to yank with text highlighting (neovim btw) Comment deleted
So many comments on this issue yet no one has found a solution. Very repeatable in Excel for me Comment deleted
I do ctrl + x, ctrl + z, ctrl + v Comment deleted