It would be immensely useful to have the ability to select multiple items in Klipper at random. One possible solution is to allow each item to have a check box that could be selected or deselected. All selected items could then be allowed to be pasted. Reproducible: Didn't try Expected Results: Select multiple items concurrently. Paste all items.
I'm sorry, but this feature request doesn't make sense. One can only have one entry in the clipboard which makes selecting multiple entries rather pointless. That's a technical limitation of the concept of the clipboard: there can only be one entry in the clipboard. Now having multiple entries to select from (a history) is exactly what Klipper provides. You click an entry in the history and that's the one which is going to be pasted. This sounds from the functionality exactly as what you requested. I also encourage you to explore the options and the global shortcuts for the clipboard. There are global shortcuts to pop up the history and to navigate through the history.
I'm in disagreement. First, I understand that the clipboard holds one item at a time, and that Klipper allows a person to select any item from the history. Second, what I propose is this: To have multiple entries to select from (the history) and make multiple selections *at the same time*. For example, Klipper shows seven entries in the clipboard history, I would be allowed to select 'Item number 1', 'Item number 3', and 'Item number 5'. When I go into a document, and press Ctrl+v, these three items would be pasted as if they were one entry. While the system clipboard has a limitation to hold one item only, Klipper can remember all of the items that have been selected before. I don't think it would be technicaly impossible to allow Klipper to select multiple items, combine them in one line, and then store them in the clipboard.
Sorry, but the clipboard doesn't work the way you think it works. In general one doesn't know when something gets pasted. On X11 an application sets the clipboard content and another application reads it - the setting application doesn't know that it got read. This makes your use case impossible. On Wayland clipboard works different by being a direct communication between the pasting and providing application. There one could say the copying client is informed, but in fact it isn't. Because the pasting client takes a copy of the data and on next paste it uses the already retrieved data. Overall your idea is just impossible to implement with the two platforms we have.
On my system, I can set Klipper's history limit to any number of items (currently I have about 100 items stored.) So we know that Klipper can store all these items somewhere. One possible way that a system may be implemented is like this: 1) User selects first item in Klipper's history. 2) Klipper stores this item in a temporary memory space (either RAM or a temp file), not necessarily the clipboard. 3) User selects a second item in history. 4) This second item gets aggregated in the memory space. 5) When the user is done selecting items from history, Klipper takes all of these items in the memory space and puts them as a single item in the clipboard. 6) Paste. To illustrate: Selecting from Klipper history: [ x ] One [ ] Two [ x ] Three [ ] Four [ x ] Five After pasting: One Three Five
Sorry, but that doesn't provide any advantage over the features klipper already has and sounds extremely complicated to me.
A use case would be nice to hear. Maybe your usecase can be implemented without messing with Klipper, maybe even in the application where you expect merging of multiple items. I see a big problem with the user interface. Users could either expect the items getting merged in the order they are _selected_ or in the order they are _displayed_. In the latter case, users might want to reorder them.