Quill history: decide which programmatic changes Undo should reverse

A fictional repair-note editor automatically inserts an updated equipment reference, while an author can click “Insert inspection reminder.” Those two changes both come from JavaScript, but they need different Undo behavior. The automatic reference should survive Undo; the reminder is an editing choice the author should be able to reverse.

Configure the source policy

In an application where Quill 2 and its normal styles are already loaded:

const quill = new Quill('#repair-note', {
  theme: 'snow',
  modules: {
    history: {
      delay: 1000,
      maxStack: 100,
      userOnly: true
    }
  }
});

Merge these options with the existing configuration rather than discarding toolbar, keyboard, or clipboard settings. The explicit delay and stack values match the documented defaults. The delay groups nearby changes; the stack limit counts history events, including merged events, rather than characters or saved documents.

userOnly uses the change's source. It does not inspect whether a human clicked a button that eventually called JavaScript. The caller must identify author-driven actions correctly. Quill's API source parameter documents user, api, and silent.

Mark the author's reminder as a user action

With a valid insertion position supplied by the application's existing selection handling:

function insertInspectionReminder(quill, index) {
  quill.history.cutoff();
  quill.insertText(index, 'Inspect the cable sleeve.\n', 'user');
  quill.history.cutoff();
}

The boundaries prevent this insertion from merging with the typing immediately before or after it. Invoke the function from a visible type="button" control and preserve the intended document position when that button receives focus.

For a separate automatic reference update, use the application's API edit with its api source under this policy. Quill's normal API default is api; passing the source explicitly makes this decision visible in application code. Do not substitute silent merely to keep an edit out of Undo. Suppressing change events can break other code that needs to observe the document.

Undo the reminder and inspect the result: the reminder should disappear while the equipment reference remains. Then Redo should restore the reminder. These are application acceptance checks; the code fragment alone does not demonstrate that the application's selection or reference-update routine works.

Clear history when loading a different record

If the application reuses one editor instance for another repair note, establish the new content and then clear the old stack through the actual loading path:

function loadRepairNote(quill, storedDelta) {
  quill.setContents(storedDelta, 'api');
  quill.history.clear();
}

storedDelta is the validated document supplied by the application's existing storage route. Clearing history removes its Undo and Redo stacks. It does not delete the document, save it, or erase a server revision log. Do not call clear() after every keystroke or ordinary save: that would remove the author's ability to reverse recent editing choices.

Check record switching deliberately. Edit note A, load note B, and invoke Undo. Note A's wording must not reappear in note B. Also test whatever confirmation or recovery policy the application uses for unsaved changes before switching records.

Keep the shortcut and document result consistent

Expose Undo and Redo through the editor's normal controls. If custom keys are involved, the Quill keyboard guide explains handler ordering and propagation. Check source behavior as well as whether the key fires: an action can successfully run Undo and still reveal a wrongly classified change.

Use the repair-note fixture to test typing, the author reminder, an automatic reference update, Undo, Redo, and loading another note. Read the final note before saving. History should leave the chosen inspection instruction and the current equipment reference together; persistence still belongs to the application's normal save operation.