Restore and display compose metadata from templates and fetched details #228

New issue

Closed

opened 2026-04-13 04:19:09 +00:00 by barrettruth · 0 comments

barrettruth commented

2026-04-13 04:19:09 +00:00

Decision

forge.nvim should mirror the familiar gitcommit editing model rather than trying to invent partial read-only regions inside a normal buffer.

That means compose/edit buffers should continue to use a normal editable text buffer with a commented metadata/help block. That block is intentionally real buffer text, but it is semantically scaffolding rather than authored content.

In other words:

the title/body remain the authored payload
the metadata/help block remains a comment block
users are not prevented from editing that comment block
forge.nvim should not try to fake line-level read-only behavior in a normal markdown buffer

Philosophy / reasoning

This is more Vim-native and simpler than virtual UI or custom edit policing.

The precedent is strong: git commit buffers already present commented scaffold text in a normal editable buffer, and users understand that lines in the commented section are guidance/context rather than the real message payload.

Trying to make parts of a normal text buffer "read-only somehow" would add complexity without matching how Vim/Neovim normally models this kind of editing surface.

What should happen now

forge.nvim should restore and display all metadata it already discovers or fetches, placing it in the compose/edit comment block rather than removing it from the surface.

That includes, where available:

labels
assignees
milestone
reviewers
draft state
branch/base/source-target context
any other template-provided or fetched forge metadata relevant to the current compose/edit flow

The metadata block should be treated as advisory/display context, not as a protected form region.

Required work

expand the internal template/detail types so metadata is preserved instead of discarded
restore metadata rendering in compose/edit comment blocks
include unsupported-but-known fields in the comment block instead of silently dropping them
keep submission parsing focused on the authored content rather than the comment block
update docs/tests to make the comment-block contract explicit

Backend research required

Before backend plumbing is finalized, we need a verified matrix for each supported forge:

which template types are actually discovered in practice
- Markdown templates
- YAML issue forms
- anything forge-specific
which top-level metadata fields those templates support
which fields each backend CLI/API can fetch for issue edit / PR edit
which of those fields forge.nvim can currently submit/update
where the backends differ and whether forge.nvim should normalize or preserve those differences

This issue now tracks the product decision and the restore/display contract.

## Decision forge.nvim should mirror the familiar `gitcommit` editing model rather than trying to invent partial read-only regions inside a normal buffer. That means compose/edit buffers should continue to use a normal editable text buffer with a commented metadata/help block. That block is intentionally real buffer text, but it is semantically scaffolding rather than authored content. In other words: - the title/body remain the authored payload - the metadata/help block remains a comment block - users are not prevented from editing that comment block - forge.nvim should not try to fake line-level read-only behavior in a normal markdown buffer ## Philosophy / reasoning This is more Vim-native and simpler than virtual UI or custom edit policing. The precedent is strong: git commit buffers already present commented scaffold text in a normal editable buffer, and users understand that lines in the commented section are guidance/context rather than the real message payload. Trying to make parts of a normal text buffer "read-only somehow" would add complexity without matching how Vim/Neovim normally models this kind of editing surface. ## What should happen now forge.nvim should restore and display all metadata it already discovers or fetches, placing it in the compose/edit comment block rather than removing it from the surface. That includes, where available: - labels - assignees - milestone - reviewers - draft state - branch/base/source-target context - any other template-provided or fetched forge metadata relevant to the current compose/edit flow The metadata block should be treated as advisory/display context, not as a protected form region. ## Required work - [ ] expand the internal template/detail types so metadata is preserved instead of discarded - [ ] restore metadata rendering in compose/edit comment blocks - [ ] include unsupported-but-known fields in the comment block instead of silently dropping them - [ ] keep submission parsing focused on the authored content rather than the comment block - [ ] update docs/tests to make the comment-block contract explicit ## Backend research required Before backend plumbing is finalized, we need a verified matrix for each supported forge: - which template types are actually discovered in practice - Markdown templates - YAML issue forms - anything forge-specific - which top-level metadata fields those templates support - which fields each backend CLI/API can fetch for issue edit / PR edit - which of those fields forge.nvim can currently submit/update - where the backends differ and whether forge.nvim should normalize or preserve those differences This issue now tracks the product decision and the restore/display contract.