Increase clipboard capacity beyond one item

[jidanni]

Just the other day I was putting a bench, a toilet, a bench, a bench, a toilet ... in some park, and I thought to myself, "Gee it sounds like some other discussion I was reading".

The single depth clipboard has got to go. At least have five slots to keep items in, and don't even time-expire them like in that discussion.

[contrapunctus-1]

I too would like this feature. My proposal is similar to how the kill ring commands work in Emacs.

When you "Paste object", a small FAB should be displayed near the green ➕ FAB. (The icon I suggest is the paste symbol with circular arrows similar to those used for way reversal, OR the paste symbol with a clock symbol.) Tapping this FAB should replace the pasted object with the previous item in the clipboard ring, cycling through the ring. Undo can be used to cycle backwards. Performing any other editing operation hides the paste cycling FAB.

The object that is finally pasted - i.e. the object left on screen when the FAB is hidden - is moved to the front of the clipboard ring. The next paste will insert this object.

The clipboard cycling button should probably not appear after, nor affect, the "Paste multiple times" operation.

Clipboard depth should be configurable.

[contrapunctus-1]

I had some doubts about how useful a clipboard ring would be, but recent sessions have proven the idea's worth.

I have a different idea about the UI now - in the paste action mode, show a bar (probably at the bottom) showing a scrollable list [1] of the clipboard contents, in the form of icons as discussed in #2239. Typical phone screens can probably accommodate five items without scrolling, which is quite sufficient for me. The most-recently-used clipboard item should be highlighted. To change what is to be pasted, tap the desired clipboard entry. The item that is finally pasted is moved to the recent-most position.

Benefits -

1. The standard case of "paste the most recent item" remains just as fast as it is now. (Just like the earlier suggestion.)
2. The latest five or so clipboard entries can be visualized (fixing #2239) without any extra user action.
3. The latest five or so clipboard entries can be used with a single extra tap from the standard case. In comparison, cycling takes N–1 steps to paste the Nth item.
4. Implementation should be easier, since there's no cycling for Undo to handle.

[1] I typically find sideway scrolling to be irritating, but it is likely to be rare in this case...at least for me. Swiping can be made more tolerable by scrolling one "screenful" on each swipe, rather than a little amount.

[simonpoole]

Questions wrt the exact semantics:

• ring or stack? ring implies a pointer to the current "active" object and pasting it doesn't change the ordering of the clipboards, stack implies last pasted clipboard moves to the top changing the ordering (note that this is orthogonal to how you select the current clipboard).
• fixed sized or not? fixed size implies copying, or cutting, creates a new clipboard removing the oldest entry, unbounded makes selecting older elements difficult besides the issues with outdated contents etc.
• unified cut and copy clipboards or separate ones? cutting removes the original element that then can be pasted exactly once, freeing the clipboard, variants of this are possible, but in general it might be confusing having an unified list with certain elements having different behaviour.

[contrapunctus-1]

In Emacs it's called the kill ring but the behavior matches your stack description.

Size should probably be fixed, and customizable.

Emacs has a unified ring for both cut and copy, and you can paste cut objects repeatedly, i.e. pasting cut objects does not clear the clipboard.

[simonpoole]

Text fragments aren't quite the same thing as OSM objects, cutting the object in Vespucci retains its id so even if you copied it automatically for further pastes it isn't really comparable.