Indeed, it is the weight of having something interrupted or unfinished. Putting it in a clipboard manager feels like the task is no longer weighing on your working memory, and it completes the first part by reaching a checkpoint.
I mostly freed myself from that weight with a clipboard manager. LaunchBar[0] on macOS and CopyQ[1] everywhere else. It’s nice to know I can Cut1/Cut2/Cut3, then Paste2/Paste1/Paste3 to my heart’s content with no worries of overwriting the contents of the clipboard forever.
It’s one capability I sometimes miss on my i(Pad)OS devices.
I've overwritten my clipboard multiple times by accident, so I think that weight is the fear of losing what I copied. To be honest, the clipboard bears the weight of so much productivity, even though by default, its functionality is pretty limited. It's the poor man's IPC, after all.
You could use a clipboard manager to get rid of that weight. KDE comes with Klipper, which remembers the last N things you copied, and makes this N configurable (I do increase the default). It also provide a lot of nice features too, like search in the history, make the copied text into a QR Code or invoke an action on the copied text, make a preview entry the current one.
dd deletes the line under the cursor. "dd deletes something into the d register (the " is part of the command that selects the register). "d selects the register. The second d is the delete command. So you could do something like "dd2w to delete the next two words and save them into the d register. The same thing works with any named register, so a less confusing example might have been "cd2w to delete into the c register.
For me, the two things don't go to the same register, but for you, you can select the old URL and paste over it (vWp) instead of deleting and then pasting (dvWP).
I got really annoyed by this, so made it so dd just deletes rather than adding to clipboard. If I really want to "cut" I highlight in visual select mode and press x.
Having the common deletion operation also default to adding to clipboard is a design mistake in Vim, I feel.
I think it's because when you copy something to clipboard you are also putting a note in your short term memory about it. Our short term memory isn't very good, with only a few slots for storage. A way around this could be for a mini-image of the contents of the clipboard to be displayed in a corner of the screen somewhere.
like all external brains, the clipboard forces you to confront 'thinking without knowing', which can be dissonant and slow, and requires browse and search strategies rather than leaping to conclusions.
I stopped worrying about it when I installed the Ditto clipboard Manager[0]. It keeps everything, so don't have to keep track of what I copied in my short term memory. I offloaded that task to the computer. Turns out they're good at that kind of thing.
I use ditto too and set it so it has everyting I copied in the last 2 weeks. It's really nice to be able to instantly retrieve some text which I copied 4 days ago, for example.
It’s such an unassuming piece of software but it might be the most important executable on my laptop. It’s basically an instant notebook. Find anything remotely interesting? Just CTRL-C it and it’s there whenever I need it.
The Windows clipboard manager doesn't support search. Ditto does. As soon as you open it you can just type a subset of some thing you recall copying the other day and it will immediately filter to that entry (or those entries). Biggest reason.
Ditto also rearranges the items so the last pasted is at the top rather than the last copied. This is also helpful because if I'm pasting something regularly, it's nice for it to be at or near the top.
You can configure how much history you want Ditto to store, by days or number of entries.
The Ditto clipboard entries are not as visually bulky as the Windows clipboard history entries.
The Ditto window can be resized, the Windows clipboard manager cannot be.
Those are the main reasons for me. Ditto also has a bunch of more advanced features but I've never used them.
Ditto is really good. I've been using it for a long time too.
Not only does it store a bunch of things but it's really easy to search through existing clips, especially text.
It's also:
- Extremely efficient from a runtime perspective, it uses ~2mb of memory
- Loads nearly instantly when you invoke it
- Very easy to paste something without formatting (surprisingly useful)
- Open source
It's in the same category of greatness as IrfanView and foobar2000 for Windows apps that I'll likely use until the end of time.
To all of you who stopped worrying thanks to a clipboard manager, how do you handle sensitive contents in your clipboard?
For example, I routinely copy-paste my passwords from KeePass, and I have disabled all clipboard management to avoid copies of my passwords lingering around.
I see this happening also with the default clipboard manager in windows and 1password - copied passwords do not show up in the clipboard menu (downside they are not pastable in VMs either)
> default clipboard manager in windows and 1password - copied passwords do not show up in the clipboard menu
Mmm, Windows Clipboard does saves the password that I copied from Keepass, they will be in the menu. However Keepass have a option to clear the last entry in the clipboard which is set for 10 second to let the password persist in the clipboard and then Keepass will overwrite/remove the last entry after the time is up. Very useful imo.
I seem to have drifted to the exact opposite: no clipboard manager, and when I want to cut/copy something and have it persist for longer, I just paste it in a notepad application.
I copy/paste passwords much more often than I require multiple clipboard entries alive together.
Try it. I was initially worried about this. Turns out with KeePassXC and Klipper it Just Works™ and fields copied (via keyboard shortcut) somehow don't get stored in the clipboard history at all.
Yes, KeePassXC actually has a little UI element in the lower right of the window that shows when it will clear a copied password out of the clipboard history.
At least one keepass implementation has the option to clear the clipboard after a few seconds. Haven't been at my Windows PC for months, can't remember details. No idea how that would work with clipboard managers, though.
I'm using Raycast on macOS. When I copy a password using 1Password, the copied text does not end up in Raycast's clipboard history. It might be possible that other password and clipboard managers do the same.
Good point, wondering the same thing. I'm considering starting using a password manager, but my bigest concern is that malware can capture the passwords by listening to clipboard. The model in my head on Windows from programming using WIN32 API two decades ago is that any application can read clipboard contents as often as it wants to. Assuming the malware does that in a tight loop, how can password managers be secure at all? I imagine X Window System is no better in this respect. Has anyone given this any thought? Are my concerns unfounded?
This is still a concern. I do malware analysis for a living and most windows malware these days that steal clipboard data simply hook the windows APIs and grab a copy of everything in there.
Thanks. What would be your recommendation regarding password managers? Does using a password manager's browser extension (assuming it has one) help here or does that also use clipboard? I guess I'm damned either way because I'm gradually migrating to using generated passwords which I copy via clipboard anyway.
I solved this problem by using Qubes OS, with isolated VMs for everything and inter-VM secure text copy. The passwords are stored in plain text in an offline VM, no password manager is necessary (but you still can use it if you like).
Your concerns aren't unfounded, but they're a bit misplaced. Password managers aren't intended to protect you from a local attacker, on your machine, like the malware you described. It is trivial to capture clipboard contents, as you say, but it's also similarly easy to keylog so your passwords would be exposed either way. If you consider your computer compromised or antagonistic like this, don't use it for anything sensitive.
Password managers are mostly intended to help facilitate unique passwords per account, to avoid password re-use which prevents credential stuffing. That is, if an attacker gets a hold of your password from one website they can't use it to log in everywhere.
Back to your concern, there isn't a solution for Windows in this space at the moment. Malware that's alive in your user context (or Satya forbid, SYSTEM) can do quite a bit thanks to Win32 APIs.
If I'm not wrong you can configure KeepassXC to only store credentials in the clipboard for a selected timespan (like 5, 10 or 30sec). You can also eliminate it entirely IIRC by using the autotype feature when entering credentials.
You can, but AFAIK the way it does that is by overwriting the clipboard with null data. If you have a clipboard manager, it may save your credentials before it is overwritten so that it can retrieved later, and in this case, it is not something you want. Some clipboard managers can be clever and detect a null overwrite and interpret it as a request not to save the overwritten content.
Autotype do not suffer this problem and is generally considered safer. Some password managers have an even safer "mixed" mode where part of the password is in the clipboard and another part is auto-typed, meaning you have to monitor both the keyboard and the clipboard to grab the password
At least one possible fix would be a clipboard management standard such that an application can both set and clear or overwrite a specific clibpoard entry's data.
(I'd prefer the clear/overwrite myself.)
Another option would be specific IPC such that clipped content is available to one and only one other application or process. There was a recent HN submission on the Unix password manager utility "pass", including the ability to supply passwords to a command via shell expansion rather than as a command-line parameter. The former doesn't reveal the password in either process listings or shell history, the latter does.
That's a relatively primitive option, a more robust standard might also be provided.
I try and copy the password only so that on the very odd chance someone combs through my clipboard history they still wouldn’t know what site or username it matches. I tend to use unique/generated usernames or emails as much as I can so that I’m not “1337wiz” on every website I have an account on.
Blacklisting BitWarden in the clipboard manager. If I copied from another app, it's four extra keystrokes to paste and delete: Cmd+V -> Cmd+Shift+V -> Cmd+Delete -> Esc.
Under X, the clipboard is especially heavy: you have two ways to copy and paste (Ctrl+c/v versus selection and middle mouse button), and Ctrl+v doesn't work in terminals. It's confusing.
Interesting, I never looked into clipboard managers.
I often have to copy X and Y coordinates from two fields to the same fields in another instance of the application. Is there an easy way to copy both values and only then switch to the other instance and paste them?
In Excel? Click on field X, press and hold ctrl and click on field Y to mark both fields, then just copy&paste should work.
Otherwise this is up to the app. A generic clipboard has no concept of the content of X and Y being in different fields (because it has no clue what a "field" is). It just stores the content.
I have a tangentially related issue. It's completely irrational, but I can't shake it. Sometimes when writing code, I need to add a block that looks a lot like an existing one, so I'll copy it and paste just below. (Yes, I know, DRY. Sue me :)
The irrational part comes in when it's time for me to make the tweaks. Maybe I'm working on a yaml config file, and I need to specify two objects that are mostly the same, with minor changes to one of them.
I'll make sure I'm working on "the copy", and not "the original". So, let's say I start with this:
- author: E. Hemingway
title: The Old Man and the Sea
medium: hardcover
edition: 1
published: 1952
And the project manager says I need to add the second edition paperback to the list. I'll find that block, copy the whole thing, and *then make sure I don't disturb the "original":
- author: E. Hemingway
title: The Old Man and the Sea
medium: hardcover
edition: 1
published: 1952
- author: E. Hemingway
title: The Old Man and the Sea
medium: trade
edition: 2
published: 1953
Basically, I've internalized that my bits have a color[1].
It makes some sense. You don't want to accidentally make some of your edits on one version and some of them on the other version. That would mean that you end up with wrong data, and also have to slowly unwind your changes correctly, if you want to get back the original.
So you have to arbitrarily choose one and keep in your mind that that's the one to be edited. You could choose the 'bottom' one. But because object persistence is pervasive, you choose the 'new' one.
The irrationality comes from the fact that I end up with exactly the same text file no matter what. My edit path (directed graph of atomic edits that arrive at the new file) can go many ways to the same result, but I find myself hating one path, and liking another. Even in the "good" path results in more keystrokes during editing. When I save my changes to git or svn or whatever, the new file will be the same regardless of edit path taken to create it. But during the editing operations, I had a nagging pull to make sure the characters I changed were from the copy.
A) why is this irrational, and if so, why is irrational sub-optimal given that the issue involves a non-(fully)-rational system (you)?
B) The habit seems very effective, why would you want to 'shake' a very efficient process?
C) DRY is an end-state which makes sense for (some) code. It is not at all clear that it makes sense for i.e. yaml config files, where it is expected that numerous items may have many similarities.
Sounds to me that by internalizing that bits are colored you have improved your engineering skills.
A, B) I'm not sure I did a good job illustrating with my example. But there are times when the new text needs to appear above the text I copied. In that case, I'll take extra effort to paste the section to edit above the existing, to make sure I'm editing the "new" text. Even if it takes a bit more effort to position my cursor above the copied text.
So in vim, I might yank an entire line and paste it immediately ("yyp"). This automatically pastes below the yanked line and positions the cursor on the new line. But let's say I want to make the edit above the existing. This situation is wrong. The new line was just pasted below the existing. Even though I'm looking at a pair of perfectly identical lines in the file, and could make my edit wherever I choose, I have this idea that one of those lines is the original and the other is the copy. And I don't want to edit the original. In other words, whether I "do it wrong" or "do it right", the end result will be bit-for-bit identical. But one of those edit paths bothers me and the other one doesn't.
So in the yanking and pasting process, I'll take the extra time to move my cursor above the copied line, then paste it in so as to preserve the "lineage" of the text.
This has nothing to do with version control or any other actual efficiencies. It's just my brain being weird. I don't gain any actual benefit, just a calm mind :)
C) Yeah, I was just heading off any nitpicks about my comment.
I have a custom keybinding (super key + c) that will bring up the Rofi menu to fuzzy search through previously copied items or pinned items. Super handy when writing code, finding old snippets, etc.
Not to me, because in the software I use the thing gets actually deleted once I paste it somewhere else, not before. It's more like tagging the thing(s) for moving to a location to be disclosed later.
It could get deleted in other ways (for instance YouTube has this horrible habit of deleting your comment in progress when you finish watching a video).
I always use cut (+ immediately paste back if needed) rather than copy because it gives me the visual confirmation that the object has indeed been put in the buffer.
Can you say a bit more about how it compares to other clipboard apps?
From a quick look over the website I see no feature to prefer it over included standard clipboard managers like klipper, glipper, parcellite,... (or any from https://wiki.archlinux.org/title/Clipboard#Managers) and whatever win+V on windows is called.
Does anyone have a solution to sync clipboards across:
1. The system (XServer)
2. A terminal text editor (Kakoune)
3. The same text editor on another system over ssh
I currently have 1 & 2 sync'd ok, but 3 is only one-way. I use the OSC 52 escape sequence (supported by my terminal) to sync a copy on 3 to 1. But I have not figured out how to sync from 1 to 3.
I might be misunderstanding you. I have a setup such that:
When I yank to the "kakoune clipboard buffer" in kakoune (a terminal text editor), the X clipboard is updated (again through OSC 52). When I copy something to the X clipboard (either on chrome or some other program), the "kakoune clipboard buffer" is updated [0].
[0]: technically, the kakoune clipboard buffer updates itself from the X clipboard when it is read from.
I cannot relate to the article. If I cut files and do nothing - they are not deleted from the origin. If I cut text - texts are versioned and backed up with git or similar alternative.
Even if I would lose something, it wouldn't take too much time to restore it. If its a password - 99% of them can be recovered
As someone who used to work with spreadsheets extensively at a bank, I can tell you that some kind of stack/queue functionality would be a godsend.
For instance, in this mode you hit Ctrl+C five times, then the subsequent five Ctrl+V actions paste the data in FIFO order. It may not seem like much, but going in between app windows in order to grab data is a big time sink. Being able to copy items sequentially and then paste them sequentially would be a killer app in most Excel heavy office workflows. You could also add a toggle for LIFO, or maybe some keyboard shortcut / chording for toggling modes while the user is pasting.
I had actually tried to implement this as a hobby project but truthfully, my MVP was rudimentary at best because I’m inexperienced at COM+ and developing for the Windows Shell.
Edit: I’m using ‘Stack/Queue’ loosely, not in the rigid data structure term of art way.
Thanks for sharing! As I understood, I think many clipboard managers already allow this, or at least, CopyQ and Ditto do. The approach is to just copy all the items you need, and then press "Win+V 5" five times. 5 would paste the fifth item in the history, but every time you did that, it is pulled to the top of the list, putting the next item in that spot.
Thank you for sharing as well, I’ll have to give those two programs a try because they seem to be doing what I was hoping for. Best of luck on your project!
I hope you're going to build only a sync plugin like suggested and not a whole clipboard manager.
Nobody needs yet another clipboard manager as there is almost a perfect one out there. Which can be extended by plugins! (I don't think it's a valid approach to start a new project because some project doing most of the wanted stuff isn't "perfect". The result is almost always "yet another 80% solution").
The "limited" number of entries is not an issue, imho. You can set it to x-thousand entries if you like. (One thousand entries are enough for more than two weeks of history for me. A clipboard is not a means of permanent data storage at all so this is fine; even one can have something akin to permanent entries by just using tabs in CopyQ).
Implementing in CopyQ some of the suggestions mentioned here would be great though!
I don't think a sync plugin would work. Entire parts of CopyQ's architecture would need to be redesigned, which would affect the rest of its ecosystem.
You can read the issue I filed in CopyQ's repository back when I switched to Linux and had to stop using Ditto for the justifications of infinite history:
https://github.com/hluk/CopyQ/issues/510
CopyQ is also bound to use Qt's clipboard implementation, which provides the common subset of Qt's supported platforms, with all the consequent limitations. See the other issues I filed for details.
It swaps the current selection with the contents of the clipboard (replacing the clipboard with the selection, replacing the section with the prior contents of the clipboard — a swap).
It's a nerdy ask, if anything adds more complexity to the clipboard concept. But I have found myself having a need for this shortcut often.
In vim that's what happens if you select some text, then paste. Honestly I sometimes want to turn this off, as I want to paste the same thing multiple times, and I resort to putting the fragment to paste into a named register.
I have always wanted a "clipboard firewall", such that apps on List A can never copy and paste between apps on List B. Basically two separate clipboards.
If I want to move things between them, I should open the clipboard manager and manually move an individual item, or bridge the two clipboards for a specified time, after which they go back to being isolated.
From a security perspective, I don't think it's possible to do with the standard OS APIs.
When an application makes data available in the clipboard, it's a free-for-all for every other application. The clipboard manager would have to race other applications to make a copy of the data, and then empty the OS clipboard.
APIs also may not allow making decisions based on which application requested the clipboard. It's possible to do in X11, but not Windows.
This goal could be achievable by intercepting the OS clipboard API. On X11, this can be done by MITM-ing the connection to the X server - https://github.com/CyberShadow/hax11 does this, and already has one clipboard-related security feature (disabling the selection mechanism). On Windows, the best bet is probably global DLL injection and API hooks, but applications can "opt out" by running as a different user or requesting a higher integrity level.
I wonder if it could be done with AutoHotKey. Perhaps having a global script variable for each List. AutoHotKey already supports interacting with the clipboard and targeting different Apps/Windows based on a number of criteria (class, title, exe, pid). So when you hit Ctrl+c or Ctrl+v you would hit logic to direct the clipboard contents to one of your list variables, then when you hit Ctrl+v it would do a similar check. You could even map a different key for a "global" clipboard (e.g. Ctrl+Shift+v or the rightCtrl+v).
All of my AutoHotKey triggers are off of the right control since I noticed a long time ago that I never use it regularly. In the old days (~2004) I would use it to write HTML. Hitting right Control+a for example would surround the text with an <a> and have logic for @ or http: etc - or hitting right Control+l would surround a list of items with <ol><li>. These days I have very few macros, the most useful one being code that will "type" what's on my clipboard rather than paste it which is useful for places that don't allow pasting.
While there definitely are good use cases where rich text clipboard should be supported, for me personally a major use case requires eliminating rich text - where I'm frequently pasting some data from some web system into e.g. a word document and I want to explicitly paste just the text, because it really does not matter what styling the web page used for some ID. Word's "Paste Special"->"Unformatted text" is horribly inconvenient, so currently I just paste it in my text editor and re-copy it, ensuring that only the text remains in the clipboard.
One clipboard feature/mode I’d like to have is "append to current clipboard content" (for text). I.e. like `>>` vs. `>` in the shell. Not multiple clipboard entries, just a single one that is textually appended to.
The clipboard manager I used on Windows, which only works there and hasn't been supported for a while, allowed a "Win+V, type, enter" workflow to very easily search for whatever I "type"d as a substring, and paste that entry. No interacting with menus, no up/down presses, no mouse. I miss that feature.
138 comments
[ 2.9 ms ] story [ 218 ms ] threadI would say it's the Zeigarnik effect
https://en.wikipedia.org/wiki/Zeigarnik_effect
I find Clipboard managers remove this. Since putting it into the queue is a whole task.
https://en.m.wikipedia.org/wiki/Ovsiankina_effect
Very similar to when you remember something that you want to write down before you forget it again.
It’s one capability I sometimes miss on my i(Pad)OS devices.
[0] https://obdev.at/products/launchbar/index.html [1] https://hluk.github.io/CopyQ/
I feel limited without a clipboard manager now.
Well:
1/ copy URL from browser
2/ alt tab to vim notes
3/ delete old URL from notes
4/ paste new URL but get the old URL instead?!
How do I do the FORTH equivalent of swapping the two items on the top of the stack (and have a stack in the first place)? :)
I also really like junegunn/vim-peekaboo, which really helps if I know I copied something, but I'm not sure how far down the stack it is.
One solution I have in vim which I always forget to use is adding an additional d or p to use a secondary paste buffer:
vnoremap dd "ad
nnoremap ddd "add
nnoremap pp "ap
To paste the copied URL instead of the deleted one, you can paste from the 0 register by using "0p.
Otherwise, depending on your system, pasting from the * or + registers (using "*p or "+p) will paste what you copied from the browser.
Having the common deletion operation also default to adding to clipboard is a design mistake in Vim, I feel.
https://github.com/inkarkat/vim-ReplaceWithRegister
This works even if I ssh into something.
john crowley's little big is sort of about this
I wrote about it back in 2016 on my very ugly website: https://www.tidbitsfortechs.com/2016/02/clipboard-manager/
[0]https://ditto-cp.sourceforge.io/
It was super easy to customise and once I'd setup shortcuts for everything, never needed to open the app window in 2+yrs
[0](http://clipdiary.com/)
Ditto also rearranges the items so the last pasted is at the top rather than the last copied. This is also helpful because if I'm pasting something regularly, it's nice for it to be at or near the top.
You can configure how much history you want Ditto to store, by days or number of entries.
The Ditto clipboard entries are not as visually bulky as the Windows clipboard history entries.
The Ditto window can be resized, the Windows clipboard manager cannot be.
Those are the main reasons for me. Ditto also has a bunch of more advanced features but I've never used them.
Not only does it store a bunch of things but it's really easy to search through existing clips, especially text.
It's also:
It's in the same category of greatness as IrfanView and foobar2000 for Windows apps that I'll likely use until the end of time.If anything, replies here should suggest the missing word
For example, I routinely copy-paste my passwords from KeePass, and I have disabled all clipboard management to avoid copies of my passwords lingering around.
edit: ah, nevermind, it's just not exposed to .NET, search for "CanIncludeInClipboardHistory" here: https://docs.microsoft.com/en-us/windows/win32/dataxchg/clip...
edit2: also some ideas to use the API from autohotkey for concerned people like me: https://www.autohotkey.com/boards/viewtopic.php?t=97251
Mmm, Windows Clipboard does saves the password that I copied from Keepass, they will be in the menu. However Keepass have a option to clear the last entry in the clipboard which is set for 10 second to let the password persist in the clipboard and then Keepass will overwrite/remove the last entry after the time is up. Very useful imo.
I copy/paste passwords much more often than I require multiple clipboard entries alive together.
Additionally you can configure apps to be ignored for the clipboard history feature.
Password managers are mostly intended to help facilitate unique passwords per account, to avoid password re-use which prevents credential stuffing. That is, if an attacker gets a hold of your password from one website they can't use it to log in everywhere.
Back to your concern, there isn't a solution for Windows in this space at the moment. Malware that's alive in your user context (or Satya forbid, SYSTEM) can do quite a bit thanks to Win32 APIs.
Autotype do not suffer this problem and is generally considered safer. Some password managers have an even safer "mixed" mode where part of the password is in the clipboard and another part is auto-typed, meaning you have to monitor both the keyboard and the clipboard to grab the password
(I'd prefer the clear/overwrite myself.)
Another option would be specific IPC such that clipped content is available to one and only one other application or process. There was a recent HN submission on the Unix password manager utility "pass", including the ability to supply passwords to a command via shell expansion rather than as a command-line parameter. The former doesn't reveal the password in either process listings or shell history, the latter does.
That's a relatively primitive option, a more robust standard might also be provided.
It is also very useful, but if you don't want it many clipboard managers have a simple checkbox to just have one clipboard.
For instance "synchronize clipboard" in this screenshot: https://www.putorius.net/wp-content/uploads/2019/12/gpaste-g...
I often have to copy X and Y coordinates from two fields to the same fields in another instance of the application. Is there an easy way to copy both values and only then switch to the other instance and paste them?
Otherwise this is up to the app. A generic clipboard has no concept of the content of X and Y being in different fields (because it has no clue what a "field" is). It just stores the content.
Or with primary selection: select X and press ctrl+c, select Y; ctrl+v to insert X, middle-click to insert Y.
The irrational part comes in when it's time for me to make the tweaks. Maybe I'm working on a yaml config file, and I need to specify two objects that are mostly the same, with minor changes to one of them.
I'll make sure I'm working on "the copy", and not "the original". So, let's say I start with this:
And the project manager says I need to add the second edition paperback to the list. I'll find that block, copy the whole thing, and *then make sure I don't disturb the "original": Basically, I've internalized that my bits have a color[1].[1] https://ansuz.sooke.bc.ca/entry/23
So you have to arbitrarily choose one and keep in your mind that that's the one to be edited. You could choose the 'bottom' one. But because object persistence is pervasive, you choose the 'new' one.
Bits have a colour, sure, but they have a(t least one) history as well, and that at least can be reasoned about mathematically.
B) The habit seems very effective, why would you want to 'shake' a very efficient process?
C) DRY is an end-state which makes sense for (some) code. It is not at all clear that it makes sense for i.e. yaml config files, where it is expected that numerous items may have many similarities.
Sounds to me that by internalizing that bits are colored you have improved your engineering skills.
So in vim, I might yank an entire line and paste it immediately ("yyp"). This automatically pastes below the yanked line and positions the cursor on the new line. But let's say I want to make the edit above the existing. This situation is wrong. The new line was just pasted below the existing. Even though I'm looking at a pair of perfectly identical lines in the file, and could make my edit wherever I choose, I have this idea that one of those lines is the original and the other is the copy. And I don't want to edit the original. In other words, whether I "do it wrong" or "do it right", the end result will be bit-for-bit identical. But one of those edit paths bothers me and the other one doesn't.
So in the yanking and pasting process, I'll take the extra time to move my cursor above the copied line, then paste it in so as to preserve the "lineage" of the text.
This has nothing to do with version control or any other actual efficiencies. It's just my brain being weird. I don't gain any actual benefit, just a calm mind :)
C) Yeah, I was just heading off any nitpicks about my comment.
One of the key things I can't go without now in my workflow is a clipboard manager.
I use Rofi (https://github.com/davatorium/rofi) in combination with Greenclip (https://github.com/erebe/greenclip) and it's a Godsend.
I have a custom keybinding (super key + c) that will bring up the Rofi menu to fuzzy search through previously copied items or pinned items. Super handy when writing code, finding old snippets, etc.
Can't recommend it enough.
Not to me, because in the software I use the thing gets actually deleted once I paste it somewhere else, not before. It's more like tagging the thing(s) for moving to a location to be disclosed later.
I always use cut (+ immediately paste back if needed) rather than copy because it gives me the visual confirmation that the object has indeed been put in the buffer.
[0] https://maccy.app/
From a quick look over the website I see no feature to prefer it over included standard clipboard managers like klipper, glipper, parcellite,... (or any from https://wiki.archlinux.org/title/Clipboard#Managers) and whatever win+V on windows is called.
I currently have 1 & 2 sync'd ok, but 3 is only one-way. I use the OSC 52 escape sequence (supported by my terminal) to sync a copy on 3 to 1. But I have not figured out how to sync from 1 to 3.
When I yank to the "kakoune clipboard buffer" in kakoune (a terminal text editor), the X clipboard is updated (again through OSC 52). When I copy something to the X clipboard (either on chrome or some other program), the "kakoune clipboard buffer" is updated [0].
[0]: technically, the kakoune clipboard buffer updates itself from the X clipboard when it is read from.
Even if I would lose something, it wouldn't take too much time to restore it. If its a password - 99% of them can be recovered
- The system should be able to efficiently store, manipulate, and search an unlimited number of clipboard entries with reasonable performance.
- The software should be cross-platform, and should have implementations for major desktop platforms (Windows, X11, Wayland, macOS).
- Non-text data (images) and rich text (e.g. HTML) should be supported.
- Clipboard history can be shared across instances using a network connection.
- Instances may temporarily go offline, and sync up with other instances once a connection is re-established.
- - All functionality should continue to be available when offline (other than sync).
- Deletions must be propagated across instances.
- Deleted clips must not be trivially recoverable.
- Deleted clips must be deleted everywhere, including any copies in OS clipboards.
- Sync should be incremental (and otherwise generally efficient).
- When connected, actions should propagate across instances in real time (instantly, as opposed to polling, and with no unnecessary roundtrips).
- Relaying should be supported (in a `A <-> B <-> C` scheme, A should be able to see C's actions).
- Network topology cycles should not result in a feedback loop.
- It should be safe and easy to simply copy the database file to another host, "pre-seeding" the clipboard history.
- Support "portable installs" (carrying the software, configuration, and database on portable storage).
- It should be easy to write interoperable implementations of bridges/clients in most programming languages.
- Non-GUI functionality should be separated (or separatable) from GUI functionality, so that a GUI toolkit doesn't need to be loaded at all times.
Any suggestions?
https://pasteapp.io/
For instance, in this mode you hit Ctrl+C five times, then the subsequent five Ctrl+V actions paste the data in FIFO order. It may not seem like much, but going in between app windows in order to grab data is a big time sink. Being able to copy items sequentially and then paste them sequentially would be a killer app in most Excel heavy office workflows. You could also add a toggle for LIFO, or maybe some keyboard shortcut / chording for toggling modes while the user is pasting.
I had actually tried to implement this as a hobby project but truthfully, my MVP was rudimentary at best because I’m inexperienced at COM+ and developing for the Windows Shell.
Edit: I’m using ‘Stack/Queue’ loosely, not in the rigid data structure term of art way.
Would this work, or is there more to it?
https://hluk.github.io/CopyQ/
If I would guess, I would assume there is already one somewhere.
If there isn't maybe just using Syncthing would be enough?
https://syncthing.net/
Nobody needs yet another clipboard manager as there is almost a perfect one out there. Which can be extended by plugins! (I don't think it's a valid approach to start a new project because some project doing most of the wanted stuff isn't "perfect". The result is almost always "yet another 80% solution").
The "limited" number of entries is not an issue, imho. You can set it to x-thousand entries if you like. (One thousand entries are enough for more than two weeks of history for me. A clipboard is not a means of permanent data storage at all so this is fine; even one can have something akin to permanent entries by just using tabs in CopyQ).
Implementing in CopyQ some of the suggestions mentioned here would be great though!
You can read the issue I filed in CopyQ's repository back when I switched to Linux and had to stop using Ditto for the justifications of infinite history: https://github.com/hluk/CopyQ/issues/510
CopyQ is also bound to use Qt's clipboard implementation, which provides the common subset of Qt's supported platforms, with all the consequent limitations. See the other issues I filed for details.
In addition to: cut | copy | paste
Add: swap
It swaps the current selection with the contents of the clipboard (replacing the clipboard with the selection, replacing the section with the prior contents of the clipboard — a swap).
It's a nerdy ask, if anything adds more complexity to the clipboard concept. But I have found myself having a need for this shortcut often.
Maybe others have as well.
If I want to move things between them, I should open the clipboard manager and manually move an individual item, or bridge the two clipboards for a specified time, after which they go back to being isolated.
Is that sensible/practical?
When an application makes data available in the clipboard, it's a free-for-all for every other application. The clipboard manager would have to race other applications to make a copy of the data, and then empty the OS clipboard.
APIs also may not allow making decisions based on which application requested the clipboard. It's possible to do in X11, but not Windows.
This goal could be achievable by intercepting the OS clipboard API. On X11, this can be done by MITM-ing the connection to the X server - https://github.com/CyberShadow/hax11 does this, and already has one clipboard-related security feature (disabling the selection mechanism). On Windows, the best bet is probably global DLL injection and API hooks, but applications can "opt out" by running as a different user or requesting a higher integrity level.
All of my AutoHotKey triggers are off of the right control since I noticed a long time ago that I never use it regularly. In the old days (~2004) I would use it to write HTML. Hitting right Control+a for example would surround the text with an <a> and have logic for @ or http: etc - or hitting right Control+l would surround a list of items with <ol><li>. These days I have very few macros, the most useful one being code that will "type" what's on my clipboard rather than paste it which is useful for places that don't allow pasting.
>^v:: SendRaw %clipboard% Return
While there definitely are good use cases where rich text clipboard should be supported, for me personally a major use case requires eliminating rich text - where I'm frequently pasting some data from some web system into e.g. a word document and I want to explicitly paste just the text, because it really does not matter what styling the web page used for some ID. Word's "Paste Special"->"Unformatted text" is horribly inconvenient, so currently I just paste it in my text editor and re-copy it, ensuring that only the text remains in the clipboard.
Edit: I see Microsoft Word doesn't natively have that shortcut, but there are two ways to "implement" it here: https://superuser.com/questions/988527/how-can-i-use-ctrl-sh...
Removing rich text formats is a good idea for a clipboard manager feature/plugin, though.
https://www.stevemiller.net/puretext/
I used to use PureText for this, but this morning I discovered CopyQ and now I'm enjoying its enhanced clipboard capabilities, including that feature.
Ability for keyboard-free editing, as in classical X: select to copy, click to paste.
The clipboard manager I used on Windows, which only works there and hasn't been supported for a while, allowed a "Win+V, type, enter" workflow to very easily search for whatever I "type"d as a substring, and paste that entry. No interacting with menus, no up/down presses, no mouse. I miss that feature.
- The system should be able to efficiently store, manipulate, and search an unlimited number of clipboard entries with reasonable performance.
- All functionality should continue to be available when offline (other than sync).
- The software should be cross-platform, and should have implementations for major desktop platforms (Windows, X11, Wayland, macOS).
- It should be safe and easy to simply copy the database file to another host, "pre-seeding" the clipboard history.
- It should be easy to write interoperable implementations of bridges/clients in most programming languages.
- Non-GUI functionality should be separated (or separatable) from GUI functionality, so that a GUI toolkit doesn't need to be loaded at all times.
But I'm not sure how to do this in SQLite as it probably does not fill deleted records with zero bits (but you could do that in your application):
- Deleted clips must not be trivially recoverable.
To make SQLite zero-out deleted pages, issue "PRAGMA secure_delete = on".
clip boards for different apps
regex to process entries