Whenever a new history node is committed after some undo steps, instead
of creating a new branch in the undo graph, we first append the inverse
modifications starting from the end of the undo list up to the current
position before adding the new node.
For example let's assume that the undo history is A-B-C, that a single undo
has been done (bringing us to state B) and that a new change D is committed.
Instead of creating a new branch starting at B, we add the inverse of C
(noted ^C) at the end, and D afterwards. This results in the undo history
A-B-C-^C-D. Since C-^C collapses to a null change, this is equivalent to
A-B-D but without having lost the C branch of the history.
If a new change is committed while no undo has been done, the new history
node is simply appended to the list, as was the case previously.
This results in a simplification of the user interaction, as two bindings
are now sufficient to walk the entire undo history, as opposed to needing
extra bindings to switch branches whenever they occur.
The <a-u> and <a-U> bindings are now free.
It also simplifies the implementation, as the graph traversal and
branching code are not needed anymore. The parent and child of a node are
now respectively the previous and the next elements in the list, so there
is no need to store their ID as part of the node.
Only the committing of an undo group is slightly more complex, as inverse
history nodes need to be added depending on the current position in the
undo list.
The following article was the initial motivation for this change:
https://github.com/zaboople/klonk/blob/master/TheGURQ.md
Those fifos are accessible during %sh{...} blocks, the command fifo
executes commands written to it once the write end side is closed
(multiple open/write/close sequences are supported), the response
fifo is a simple helper fifo available to write response back to
the shell process
An example use of this feature is to request some list options
content from without being limited by the environment size:
```
%sh{
echo "echo -to-file $kak_response_fifo -quoting shell -- %opt{some_list}" > $kak_command_fifo
eval "set -- $(cat $kak_response_fifo)"
}
```
Properly speaking, all expansions are of the form "%abc{}" where "abc"
is the expansion type. All expansion types are listed in the documentation, as
they should be. However, when searching through the documentation, a keyword
like "file" is likely to hit a lot of false-positives, so a smart user is likely
to search for the more-unique "%file" instead. Unfortunately, unlike every other
expansion-type, file-expansions did not include an example, so a search for
"%file" resulted in no hits, potentially leading people to believe it was
undocumented.
Now there's an example, so people searching for "%file" will find what they're
looking for.
Also, moved the "Markup strings" section to faces.asciidoc, since it wasn't
anything to do with expansions, and updated various hyperlinks to point at the
new location.
Now that we have a nice standard way to express lists of strings,
registers can be fully exposed. An new $kak_main_reg_... env var
was added to provide the previous behaviour which is relied on by
doc.kak.
