link-parser's history file location control #1534
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In this PR:
The location of the history file is according to, in this order.
XDG_STATE_HOME
HOME
The history file name is X_history when X is the dict name to support a different history file per dict. For example,
en_history
. To support using the same history file for more than one dict, X is the dict name until the first:
. For example, the dictsen
anden:test
use the save history fileen_history
.I tested it on MinGW (no editline, just that it doesn't break compilation), Cygwin, macOS, and Linux.
It cannot be tested on MSVC because the MSVC build recently became broken in more than one way (PR soon). (The only test needed for now is that the changes of this PR don't break the build, as there is no editline support for Windows.)
This PR includes a minimal XDG support module I wrote instead of using a system library. One reason is that the current libraries don't support XDG_STATE_HOME, which was added to the standard relatively recently.
Comments:
verbosity
variable is currently not in the needed scope.EDIT: I tried to configure with HAVE_ASPRINTF=0 and got a segfault. So, I forced-push a fix. (This also demonstrates that using
#if HAVE_FEATURE
is better than#ifdef HAVE_FEATURE
because it allows such easy tests.)Ref. PR #1446.