mirror of
https://github.com/mawww/kakoune.git
synced 2024-11-13 06:37:20 +03:00
e0d33f51b3
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 |
||
|---|---|---|
| .. | ||
| compose | ||
| display | ||
| highlight | ||
| hooks | ||
| indent | ||
| normal | ||
| prompt | ||
| regression | ||
| shell | ||
| README.asciidoc | ||
| run | ||
Regression test
===============
:unified-context-diff: https://en.wikipedia.org/wiki/Diff#Unified_format
Source structure
----------------
----------------------------------------------
.
├── unit
│ └── …
└── compose
└── …
├── [enabled] → applicability
├── [rc] → configuration
├── [in] → start file
├── cmd → command
├── [script] → UI automation
├── [out] → expected end file
├── [kak_*] → expected expansion values
└── [error] → expected error
----------------------------------------------
Usage
-----
To test, just type +run [test]+ in the +test+ directory.
It will print each passing test. If a test fails, a {unified-context-diff}[unified context diff]
is printed showing the test’s expected output and the actual output.
Details
-------
+enabled+ is optional.
If it exists and is executable,
it is invoked with no parameters.
If it exits with a non-zero exit code,
the test is assumed to be not applicable to the current environment
(for example, a test for OS-specific integration
isn't useful on a different OS)
and will be silently skipped.
+rc+ is optional
and should contain a sequence of commands,
_e.g._, +set-option+, +define-command+, +declare-option+.
+rc+ is sourced and evaluated before the +cmd+ key sequence is executed.
+in+ is optional
and should contain the initial text loaded into the input buffer
for editing by the +cmd+ key sequence.
+cmd+ is required
and should contain a key sequence that will edit the input buffer.
+cmd+ is executed after the +rc+ command sequence is sourced.
+script+ is optional
and is a shell-script that will be sourced after +cmd+ is executed.
The special +ui_in+ function sends a string
(expected to be a JSON UI message,
see `doc/json_ui.asciidoc` in the Kakoune source)
to the running Kakoune instance,
while the special +ui_out+ function
checks the next JSON UI messages from Kakoune
against its arguments,
and fails the test if any of them are different.
You can also say `ui_out -ignore N` to ignore the next _N_ JSON UI messages,
where _N_ is a positive integer.
+out+ is optional
and should contain the expected text generated by the +cmd+ key sequence.
If the actual +out+ text
does not match the expected content in the corresponding file,
the unit test will fail.
If there is no +out+
then the unit test will always succeed.
Any +kak_*+ files should match the corresponding expansion
after +cmd+ is complete.
For example, a file named +kak_selection_desc+
should match the +%val{selection_desc}+ expansion.
See `:doc expansions` for a list of available expansions.
If there is an +error+ file,
the test is expected to produce an error.
If Kakoune exits successfully,
or if it fails with the wrong error,
the test is marked as a failure.