emit CanolaGit events #8

Closed
opened 2026-09-21 17:53:34 +00:00 by barrettruth · 1 comment
Owner

Original issue: barrettruth/canola-collection#38
Original author: barrettruth
Original date: 2026-03-23T22:56:26Z

canola git events with a type based on the git event
so it can be easier for users to tap into the api

then add a recipe to the helpdocs that makes it easy
for people to know how to use it

> Original issue: barrettruth/canola-collection#38 > Original author: `barrettruth` > Original date: 2026-03-23T22:56:26Z canola git events with a type based on the git event so it can be easier for users to tap into the api then add a recipe to the helpdocs that makes it easy for people to know how to use it
Author
Owner

Original comment: barrettruth/canola-collection#38, comment 4293264165
Original author: barrettruth
Original date: 2026-04-22T03:09:20Z

Closing this out after the architecture review.

We are not adding a separate CanolaGit* event family. The intended extension surface is User CanolaReadPost plus require("canola-git").get_status() / invalidate(), and I added a vimdoc recipe that shows the reusable integration pattern for custom git-aware UI.

This keeps the public API aligned with canola.nvim's existing render-lifecycle events instead of exposing canola-git's internal refresh pipeline as a second event layer.

> Original comment: barrettruth/canola-collection#38, comment 4293264165 > Original author: `barrettruth` > Original date: 2026-04-22T03:09:20Z Closing this out after the architecture review. We are not adding a separate `CanolaGit*` event family. The intended extension surface is `User CanolaReadPost` plus `require("canola-git").get_status()` / `invalidate()`, and I added a vimdoc recipe that shows the reusable integration pattern for custom git-aware UI. This keeps the public API aligned with canola.nvim's existing render-lifecycle events instead of exposing canola-git's internal refresh pipeline as a second event layer.
Sign in to join this conversation.
No description provided.