Clipboard items should not be indexed solely by first line contents and number of lines

[NickHu]

Suppose I copy the text

a
b

This creates new entry in the line_cache: <timestamp> a (2 lines)

Now suppose I copy

a
c

This also creates a new entry in the line_cache: <newer_timestamp> a (2 lines).

However, clips are stored just by the cksum of this reduction (a (2 lines)) - in this case, the output of echo "a (2 lines)" | cksum, i.e. 1801649764 12 - as these two different pieces of text have the same first line contents and number of lines, the second copy overwrites the first which is fundamentally flawed behaviour.

For an example of how this might crop up naturally, suppose that the first piece of text is a piece of code I wrote. Then some time later I make a few changes, but crucially do not change the first line nor the number of lines; then the first clip is gone once I copy this.

[cdown]

This was initially a design decision rather than a bug, but yes, it's worth reevaluating now that we have better indexing time complexity.

Probably we can just also bunch the timestamp as part of the checksum. That will require some work on the vacuuming logic as well though.

[ryanthomas-org]

I regularly use scripts to copy Google Voice notifications to the clipboard and then extract URLs from them; these always have matching titles (i.e. the first line) and typically match number of lines as well. Is there an easy workaround to allow all duplicate entries?

[cdown]

This is no longer a problem in clipmenu 7 (next release) -- all entries are hashed on full content and are indexed.