this post was submitted on 07 Aug 2026
579 points (97.4% liked)

memes

22244 readers
2962 users here now

Community rules

1. Be civilNo trolling, bigotry or other insulting / annoying behaviour

2. No politicsThis is non-politics community. For political memes please go to !politicalmemes@lemmy.world

3. No recent repostsCheck for reposts when posting a meme, you can only repost after 1 month

4. No botsNo bots without the express approval of the mods or the admins

5. No Spam/Ads/AI SlopNo advertisements or spam. This is an instance rule and the only way to live. We also consider AI slop to be spam in this community and is subject to removal.

A collection of some classic Lemmy memes for your enjoyment

Sister communities

founded 3 years ago
MODERATORS
Tenthrow@lemmy.world
The_Picard_Maneuver@lemmy.world
The_Picard_Maneuver@startrek.website
579
Can't trust the C button. (lemmy.world)
submitted 1 day ago by laurenceOfSuburbia@lemmy.world to c/memes@lemmy.world
123 comments fedilink hide all child comments
 
you are viewing a single comment's thread
view the rest of the comments
[–] Zarobi@aussie.zone 6 points 1 day ago (2 children)

I have unconfirmed theories.

  • My C and V key are literally the most worn keys on my keyboard. The letters are completely worn off, they're by far my most used keys. That amount of use probably makes the contacts degrade and less reliable.
  • Windows 10 (I think?) introduced a "fancy clipboard" with history and multi paste and generally made it an "app". In my experience the fancier it is the more failure points, since it's no longer just a simple OS memory buffer, it has its own application logic.
  • Since it's a global hotkey, the OS has to:
    • Handle the interrupt
    • Query the currently active window / application for a "copy" output of the currently highlighted context
    • Wait for a response
    • Place that response into a buffer of some sort
    • In a highly volatile asynchronous UI where the user can alt tab at any time, I imagine often what happens is that you just didn't wait long enough for the data to actually copy. Pressing CTRL+C would be equivalent in reliability as waiting 2 seconds, but it's more fun to press the button a bunch
[–] SlurpingPus@lemmy.world 2 points 1 day ago* (last edited 1 day ago)

Handle the interrupt

For better or worse, usb devices need to be polled by the computer all the time, instead of delivering interrupts at the moment of input events. I'm baffled by this fact, but am not versed in hardware design well enough to weigh pros and cons. I assume that the polling is handled by the usb controller, though.

Query the currently active window / application for a "copy" output of the currently highlighted context

Place that response into a buffer of some sort

To my vague knowledge, the various GUIs all request content from the owner of the selection at the moment of pasting, i.e. ctrl-v — presumably both to avoid storing large swathes of pictures and such, and to allow conversion to the target format on the fly. However, iirc some environments require defining the available formats when content is copied, so idk how this meshes with that. I'm not a desktop programmer, so not entirely sure. Perhaps it's just to simplify copying for the programmer of the source app, instead of exposing the whole innards.

In a highly volatile asynchronous UI where the user can alt tab at any time, I imagine often what happens is that you just didn't wait long enough for the data to actually copy.

Properly, any input event would be delivered to the app (or rather the UI element) that was active at the time of the event — and presumably the OS UI runs at a higher priority for that. However, in practice it seems to be a toss-up as to whether it really works like this.

[–] flambonkscious@sh.itjust.works 2 points 1 day ago

Thanks, that's interesting - I hadn't thought about the window messages responding to update the all clipboard

It's odd to me that the paste is almost never the previous clipboard value - it's basically always null