How the clipboard works • Hacker News Board

Re: How the clipboard works

#111

Post by wizzwizz4 » Tue, Oct 25, 2022, 3:55 PM UTC

TeMPOraL wrote: post #107

dns_snek wrote: post #46

Earlier quoted context omitted.

You might want to be careful about pasting anything remotely sensitive into the URL bar as most browser automatically send your query to the search engine for auto-complete functionality.

My habit on Windows, entirely in the muscle memory after two decades of doing it, is: - If the text to sanitize is a single line: Win+R, paste, select all, cut, Esc (to close "Run" window) - If it's multiple lines: Win+R, notepad, Enter, paste, select all, cut, Alt+F4 (to close notepad) On Linux, I usually switch to Emacs, switch to a scratch buffer, then do the paste-and-cut-again dance in it.

I never changed my habits from Windows; I use the Run box, or type leafpad / mousepad. It's interesting that we've independently invented the same technique.

Re: How the clipboard works

#112

Post by wizzwizz4 » Tue, Oct 25, 2022, 3:56 PM UTC

account42 wrote: post #103

imiric wrote: post #27

Earlier quoted context omitted.

I don't think having two different clipboard implementations is a usability advantage. Only on Linux do you find yourself in the situation where one application copied to the Unix clipboard, and another tries to paste from the "secondary" (X11?) one. Standardizing on one implementation is the only sane path forward.

I have literally never run into applications mixing up the clipboard and selection on Linux - its always CTRL+C->CLIPBOARD->CTRL+V and select->PRIMARY->middleclick. Super useful to have two different scratch buffers when moving things around.

Dillo doesn't support Ctrl+C on the contents of websites, so it feels like it mixes them up; actually, it doesn't. (Ninja-edit to correct myself.)

Re: How the clipboard works

#113

Post by anentropic » Tue, Oct 25, 2022, 3:58 PM UTC

Vinnl wrote: post #50

Daub wrote: post #8

My life was significantly improved when I discovered control shift paste, which pastes just text without format. But un-desired formatting of text remain the bane of my life.

Off-topic, but a somewhat similar experience for me was learning about Alt+select. Allows you to select parts of a hyperlink without actually activating the link. (At least in Firefox.) When you first hear about it, you think "What's the big deal?", but then you quickly find that you use it pretty often.

Thank you! Seems to work in Chrome too!

Re: How the clipboard works

#114

Post by lotharcable » Tue, Oct 25, 2022, 3:58 PM UTC

School-Cotton wrote: post #82

dfox wrote: post #59

Earlier quoted context omitted.

X11/ICCCM clipboard semantics (which is arguably the same design, but with the server being part of the data transfer) was also source of many bugs and the applications/toolkits did not get it right until 00's and linux-centric desktop environments. IIRC disagreement about how to integrate Emacs' concept of kill rings with X11 selections was one of the major reasons for Emacs/XEmacs split.

> the applications/toolkits did not get it right until 00's They have still not gotten it right. I still sometimes experience the clipboard losing things on modern Ubuntu.

X11's model for 'cut buffers', 'primary', and 'clipboard' is a historically bad design.

Like very easily in the top 10 worst designs in computer science history.

The fact that it managed to work at all is a testament to the millions of man-hours people were willing to pour into polishing a turd to make Linux Desktop a reality.

If we had the ability to go back in a time machine and do it again it is now painfully obvious that X11 should of been completely abandoned by the mid-1980s. This would of saved a huge amount of heartache.

Re: How the clipboard works

#115

Post by lotharcable » Tue, Oct 25, 2022, 3:59 PM UTC

the_mitsuhiko wrote: post #106

lupire wrote: post #100

Earlier quoted context omitted.

Why can't a Go program fork into the background?

Because go uses threads.

That is kinda insane thing to say. That is like trying to claim that you can't do threads in C++ because you can fork.

Of course Go can fork processes.

Re: How the clipboard works

#116

Post by anentropic » Tue, Oct 25, 2022, 4:00 PM UTC

enriquto wrote: post #39

imiric wrote: post #27

Earlier quoted context omitted.

I don't think having two different clipboard implementations is a usability advantage. Only on Linux do you find yourself in the situation where one application copied to the Unix clipboard, and another tries to paste from the "secondary" (X11?) one. Standardizing on one implementation is the only sane path forward.

> Only on Linux do you find yourself in the situation where one application copied to the Unix clipboard, and another tries to paste from the "secondary" This never happens if you only use the unix clipboard. I agree that both methods should point to the same clipboard, but this is an implementation detail. The important thing is the interface: selecting text copies it to the clipboard, middle-clicking pastes it.

So... selecting some text by accident clears what you previously had in the clipboard?

Re: How the clipboard works

#117

Post by UI_at_80x24 » Tue, Oct 25, 2022, 4:01 PM UTC

I'm surprised there was no mention of copy/paste that existed BEFORE ctrl+c/ctrl+v

ctrl + INS (copy) shift + INS (paste)

IIRC this is a hardware interrupt in much the same way as ctrl+alt+del is. My memory is damn hazy about this (I've used DOS since MS-DOSv3.3) but I think I used that combination back in the DOS days. {instead of using the mouse to select things, shift+CURSOR would do the trick}

This might even be a C=64 trick. I can't remember 100%.

BUT Windows/Linux/BSD _STILL_ honour it's usage. (It's also a handy way to bypass some websites that block right-click & copy/paste.)

I know there are more greybeards on here, so somebody help me nail down from whence CTRL+INS & SHIFT+INS originated.

Re: How the clipboard works

#118

Post by Arrath » Tue, Oct 25, 2022, 4:03 PM UTC

UI_at_80x24 wrote: post #117

I'm surprised there was no mention of copy/paste that existed BEFORE ctrl+c/ctrl+v ctrl + INS (copy) shift + INS (paste) IIRC this is a hardware interrupt in much the same way as ctrl+alt+del is. My memory is damn hazy about this (I've used DOS since MS-DOSv3.3) but I think I used that combination back in the DOS days. {instead of using the mouse to select things, shift+CURSOR would do the trick} This might even be a…

Well I'll be. You learn a new hotkey every day.

Certainly feels like it predates the mouse, considering the innate right-handedness of the key combo.

Re: How the clipboard works

#119

Post by Arrath » Tue, Oct 25, 2022, 4:05 PM UTC

johannes1234321 wrote: post #91

alkonaut wrote: post #78

Earlier quoted context omitted.

I’m a windows desktop dev since the last millennium and tbh never knew that there was an announce api. It seems really difficult to use as a tiered solution where you only return the more complex data when asked. After all, you must then still snapshot that data from the moment the copy occurred to be able to provide a snapshot from the time of the copy later?

You snapshot the data in your application's native data format, then you can convert it later to the best match for the consumer. Taking the Excel example form above: You got to store the cell layout and values. If it's pasted into a different excel sheet you pass that structure over. If it is pasted in a richt text editor it is converted to some richt text table format. If it is pasted to a plain text editor it is m…

And at any time during this process you can easily and readily lose the copy from Excel.

God its so annoying to tab back to the sheet to hit Ctrl-C again.

Re: How the clipboard works

#120

Post by mdmglr » Tue, Oct 25, 2022, 4:11 PM UTC

This contradicts how I as a user think of the clipboard. The clipboard is the most important feature of end user computing that is ignored by OS designers. I should be able to open a window and see all things in my clipboard.

Also with password managers like 1Password using the clipboard as a means to xmit sensitive data it seems to me like the API needs to be updated.

An interesting solution to the problem discussed in the post would be how macOS implements Quick Look in Finder. Apps can serialize a data structure to clipboard and plugins can be responsible for deserialize on paste. This would solve the issue of apps being closed.

Clipboard API should have the concept of sensitive data.