Clipboard history should have a coherent storage location and support $XDG_CACHE_HOME #3692

CopyQ currently splits clipboard history across different persistent directories depending on the size of an item.

For example, on Fedora 44 with CopyQ 16.0.0:

• Smaller clipboard items are stored under:

~/.config/copyq/

• Larger clipboard items are stored under:

~/.local/share/copyq/

This makes the storage model both surprising and difficult to control.

Clipboard history is not application configuration, yet small clipboard contents are stored inside the configuration directory. Larger contents are stored as persistent application data. The result is that copied text/files can end up persisted in multiple places according to an implementation detail such as item size.

Why this is problematic

The XDG Base Directory Specification gives configuration, data, and cache separate semantics:

• $XDG_CONFIG_HOME is for user-specific configuration files.
• $XDG_DATA_HOME is for user-specific persistent application data.
• $XDG_CACHE_HOME is for user-specific non-essential cached data that can be deleted without loss of essential state.

Clipboard history is a good candidate for cache storage when the user does not want copied material to persist indefinitely.

More importantly, CopyQ should not need to store part of clipboard history in $XDG_CONFIG_HOME merely because an item happens to be below a particular size threshold. The size of a clipboard item should not determine which XDG category contains the user's clipboard data.

Requested behavior

Please provide a coherent storage policy for clipboard history, ideally allowing the user to select between:

Persistent history:
$XDG_DATA_HOME/copyq/

Ephemeral/cache history:
$XDG_CACHE_HOME/copyq/

RAM-only history:
no clipboard history written to disk

The selected storage policy should apply to all clipboard history data, regardless of item size.

At minimum, CopyQ should avoid putting clipboard contents into $XDG_CONFIG_HOME, since those contents are not configuration.

Related issue

There is already an issue concerning COPYQ_ITEM_DATA_PATH not being honored correctly by the actual CopyQ server:

#3691

That variable appears intended to control the location of large item data, but it does not provide a complete solution to the underlying problem because CopyQ still stores other clipboard data elsewhere.

The goal here is not merely to add another path override. The storage model itself should be made coherent and should give users a straightforward way to keep clipboard history in $XDG_CACHE_HOME when persistence is not desired.