WIP: Add history file support

[WPettersson]

This functions as best I can work out, but the configuration needs an
absolute location for the history file. The config file does not
interpret ${HOME} or ~, which might need discussion.

This is for issue #23

[iFreilicht]

I like it! I read the discussion in #23, and welcome this PR generally, but I'm not sure if ~/.local/state/splatmoji is the correct location for this. According to the XDG Base Directory Specification, there's two potential candidates (emphasis mine):

$XDG_DATA_HOME defines the base directory relative to which user specific data files should be stored. If $XDG_DATA_HOME is either not set or empty, a default equal to $HOME/.local/share should be used.
[...]
$XDG_CACHE_HOME defines the base directory relative to which user specific non-essential data files should be stored. If $XDG_CACHE_HOME is either not set or empty, a default equal to $HOME/.cache should be used.

rofi itself uses .cache for its history function as well. In rofi/#769, some people were unhappy with this, as they deem history not "non-essential", and in that thread .local/share was proposed as an alternative. They now have an option to set this. I think .local/share (or $XDG_DATA_HOME if set) is a good candidate, what do you think?

There also was some discussion in rofi/#747 to use rofi's built-in history mechanism for custom scripts, but that has been rejected for rofi -dmenu piped scripts, so having a custom history like this is probably the right way to go.

[WPettersson]

@iFreilicht It may be helpful to skim through #23, the associated bug, as that's where I got the ~/.local/state/splatmoji location from. I admit, I don't know the XDG spec well enough to make such a decision, but it's easy to change.

[iFreilicht]

Yes, that's what I did :) Maybe @cspeterson can comment on this, `.local/state` was his proposal after all. 22 Sep 2020 00:21:01 William Pettersson <notifications@github.com>:

…

@iFreilicht[https://github.com/iFreilicht] It may be helpful to skim through #23[#23], the associated bug, as that's where I got the ~/.local/state/splatmoji location from. I admit, I don't know the XDG spec well enough to make such a decision, but it's easy to change. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub[#24 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/ACKKSK5S7W4YAGNA7MVRVNTSG7GUVANCNFSM4RKB6UYA]. [https://github.com/notifications/beacon/ACKKSKYXT545AXZVKSW6PS3SG7GUVA5CNFSM4RKB6UYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOFGBF3PY.gif]

[cspeterson]

Okay so first considering only the "where does the recent selection list live" question... 😁

Where my suggestion came from

My suggestion of ${HOME}/.local/state} came from what I had initially read on the Debian wiki, about "proposals" for a state dir which is still lacking in the Base Dir spec:

Proposal: STATE directory

This is a recurring request/complaint (see this or this) on the xdg-freedesktop mailing list to introduce another directory for state information that does not belong in any of the existing categories (see also home-dir.proposal. Examples for this information are:

history files of shells, repls, anything that uses libreadline
logfiles
state of application windows on exit
recently opened files
last time application was run
emacs: bookmarks, ido last directories, backups, auto-save files, auto-save-list 

The above example information is not essential data. However it should still persist on reboots of the system unlike cache data that a user might consider putting in a TMPFS. On the other hand the data is rather volatile and does not make sense to be checked into a VCS. The files are also not the data files that an application works on.

A default folder for a future STATE category might be: $HOME/.local/state

https://wiki.debian.org/XDGBaseDirectorySpecification

I agree with the maillist conversation there that there is a need for something distinct from "cache" and I think the proposed location is reasonable and I know no better or more standard answer.

So if I'm actually the decider (I guess I am!?! 😅) I suppose that's the answer and I see no requirement for it to be configurable unless someone convinces me otherwise

[iFreilicht]

Huh, that's very interesting, I had no idea. You are indeed the person to decide, this is your project after all :)

And hey, if enough projects start using state and it becomes a pseudo-standard, maybe it will actually be added to the specification at some point.

[cspeterson]

@WPettersson And then for the rest of it: thanks so much for doing the work! I'll take a closer look soon and am delighted to have the new feature
└[∵┌]└[ ∵ ]┘[┐∵]┘

[cspeterson]

Okay I roped in the new code and adjusted/added tests. Thanks!