This refers to the following issues:

• Change API

• Persistent Undo

• Have an interface for the history tree, document it

• Re-removed history_id. Since we will need a separate command to set the history data, it cantake the new history_id followed by the history node data, so this does not need to be part ofthe history node data.

1. Provide all information necessary for a "Persistent Undo" plugin.

2. Provide all information necessary for a tool like parinfer-rust to inspectall the changes to the buffer since it was last seen.

3. Enable for "undojoin"-like functionality: easily amend the current historynode.

4. Be easy to parse from POSIX shell.

5. Allow for plugins to implement Vim’s:earlier.

Nice to have:

1. Use one variable, allowing history to be replaced withset-option.

2. Have the format be compact, to avoid environment variable limits.

3. Able to support cursor positions or timestamps for each node in the future.

parent<n> (integer)

Index of the parent of node <n>. The parent of node 0 is-1.

timepoint<n> (ISO-8601 timestamp in UTC)

The time the history node was first committed.

redo_child<n> (integer)

Index of the node to which we will move if the user typesU. Leaf nodesshould have-1.

modification<n>.<m> (modification)

The <m>th modification for node <n>.

Modifications are represented as `op|coord|text` strings.  `text` is at theend so it can contain arbitrary text, including pipe symbols, and still beeasily parsed by shell.

For example:

(Quotes are the quotes which might be added by shell expansion, not part ofthe format itself.)

Since each history node consists of a variable number of items, processorswill need to detect the start of the next record by checking if the currentitem is a well-formed integer. We can parse the data in POSIX sh like so:

Since modifications are tagged with+ or- in their first field, we canadd more tags. In the documentation, we warn existing processors to ignoreunknown tags.

1. The parent of node 0 must be-1.

2. Node 0 must not have any modifications.

3. The graph must be acyclic with respect to parent pointers.

4. The graph must be fully connected; every node must be reachable from theroot.

5. Everyredo_child of an internal node must point to an immediate childnode.

6. Everyredo_child of a leaf node must be-1.

7. Working backward from the supplied history ID and the current buffercontents to the root, all modifications which are insertions should bedeletable and all deletions should be insertable. This means that thecoordinate for each exists and the supplied text for insertions is presentat that coordinate.

8. Given the constructed buffer contents for node 0 created in the previousstep, itshould be possible to reach all leaves by applying the insertions ordeletions in every node.

Wiki Home Page

Onboarding

Keys

Editing

User Interface

Integration with OS and other tools

Plugins