Stop littering .lg_history files everywhere.

[linas]

They are just .. everywhere on my system. Fixes #1443

This is a Linux-only solution. I don't know what the convention for Windows and Apple should be.

[ampli]

It turned out that this change is not good.

Many years ago I mentioned that it is rather inconvenient that the history of various languages is mixed in the same file. You then told me to chdir first to the language dictionary directory before invoking link-parser. This solved my problem. Later I started to invoke link-parser only through a shell script, which can do many useful things, and among them, it changes the directory to that of the dictionary. With this change, this trick will not work.
In addition, ~/.cache/ is an XDG directory, but it is not intended for history files.

Solutions:
A. Leave it as it is currently, and just cd to the dictionary directory before invoking link-parser. Alternatively, use the script lg which I would like to eventually submit as PR. In any case - close this PR w/o applying it.
B. Implement the XDG specification for the dictionary location of the history file.

1. Basically, it should be in the directory ~/.local/link-grammar/ unless the XDG environment variables tell otherwise.
2. Use per-language history file names, e.g. lg_history-en.
3. Handle macOS the same as above (as other POSIX programs do).
4. No need for history Windows support, as Windows is built without libedit since its console supports editing.

My recommendation is to first to do A and then I will send a PR for B.

In any case, note that if the history file is maintained in a central place (and not per branch), the number of the history entries may get very big (slow link-parser startup), but this can be solved by something like history size 200 in ~/.editrc.

[linas]

• OK, yes, history files can be per-language, I guess.
• Ideally, there is some little itty-bitty library that provides the correct API for dealing with XDG. I don't want to have to read that spec and try to guess if we've implemented it correctly, or not.
• On my system, ~/.local/ has only one subdir: ~/.local/share which seems to hold config files (only). By contrast, the .cache directory seems to hold the time-varying data. So I think we'll still want to use the .cache instead of .local but I have not carefully read the spec.

I'm closing this pull req. It's not that big an issue to me: I run link-parser from 1001 different directories, depending on what I'm doing, and these history files end up as litter. I'm not going to start cding around to yet other locations, my life is already too complicated.

[ampli]

According to the spec, the .cache directory is for files that can be removed without any functional implication for the user.
The spec mentions history file in one place (I marked it in boldface):

$XDG_STATE_HOME defines the base directory relative to which user-specific state files should be stored. If
$XDG_STATE_HOME is either not set or empty, a default equal to $HOME/.local/state should be used.
The $XDG_STATE_HOME contains state data that should persist between (application) restarts, but that is not
important or portable enough to the user that it should be stored in $XDG_DATA_HOME. It may contain:
- actions history (logs, history, recently used files, …)
- current state of the application that can be reused on a restart (view, layout, open files, undo history, …)

As you can see, the default location is $HOME/.local/state. This location first appeared in the newest XDG specification, of May 2021. My system has two programs there.

Implementing an XDG location for the link-parser history using libxdg-basdir is easy, and I can send a PR.
I propose that if not configured with libxdg-basedir, the library will just continue to create the history file as it does now.

BTW, a history file in a central place also has the benefit when testing the same sentence in different branches (currently I use copy/paste for that). As I mentioned, a problem appears if it becomes very big, but a limit in .editrc should solve that. Maybe we can also make a hard limit, e.g. 500 (or even lower), in link-parser.

[linas]

I can send a PR.

Yes, sure.

we can also make a hard limit, e.g. 500 (or even lower),

Works for me. I can't imagine hitting the up-arrow key more than 100 times, anyway. searching for some old sentence.

BTW, I want to create a version 5.12.1 "real soon now". Are there any pending pull reqs I should wait for, or can I do it, whenever?

[ampli]

BTW, I want to create a version 5.12.1 "real soon now". Are there any pending pull reqs I should wait for, or can I do it, whenever?

There are some of the problems I would like to fix for the new version:

1. Fix the Emscripten problem.
2. From the problems in memory-pool.c, fix the fake pool_free().
3. General cleanup, including typo/comment fixes.
4. Fix PR Deindent if-elseif chain. Move debug printfs. #1429 (restore a check).
5. Fix and update documentation.
6. Fix a string variable setting bug in link-parser.

Maybe also add this, which I mostly finished:

1. Add #define's for enabling/disabling the various caches in do_count() (finished, I just need to merge with the latest changes).
2. Simplify the match-list cache code and reduce memory (mostly done, need to debug and test).
3. Possible addition: Add match-list cache support for null_count>0 (if turned out not to be trivial, then not for this version).
4. Possible addition: Add an alternatives-compatibility check in do_count() (to reduce the number of unsane linkages in amy) (mostly finished, needs extensive tests, will be for the next version if cannot be done in a timely manner).

Make tests:

1. Linkage test.
2. Windows tests.
3. macOS tests.

[linas]

OK.