Repository navigation
Conversation
… casing - selectedmentionlabel qualifies any mention whose name is shared by another selected identity; insertmention requalifies earlier plain namesake selections (map keys and draft text) when a namesake is added - a qualified occurrence denies the plain name on render, so a lone plain namesake never resolved; all namesakes now carry the pubkey qualifier - message_content pre-pass keeps the authored text of each mention range instead of the lowercased binding key (binding lookup lowercases itself) Co-Authored-By: Claude Opus 5.5 <[email protected]> Signed-off-by: Kalvin Chau <[email protected]>
selecting a second same-name identity now requalifies earlier selections too. Co-Authored-By: Claude Opus 5.5 <[email protected]> Signed-off-by: Kalvin Chau <[email protected]>
…dget keeps compose_bar_widget.dart within the mobile file size ratchet. Co-Authored-By: Claude Opus 5.5 <[email protected]> Signed-off-by: Kalvin Chau <[email protected]>
- mention-bindings: renameMentions appends the qualifier to each matched spelling and skips excluded spans, reporting renamed and kept keys - compose-bar: requalification excludes inline and fenced code; a key left in code stays bound beside its qualified label, so its recipient still sends and the send-time resolver sees no ambiguous bare name - agent-mention-prefill: qualify every same-name agent, including the first - docs/mention-editor: describe casing, code and prefill behavior Co-authored-by: goose-wayne <ae6b377e5b6d090ee22558d19246413a5731628a127e25371111badfd4861535@buzz.block.builderlab.xyz> Signed-off-by: Kalvin Chau <[email protected]>
requalification skipped occurrences by independent per-rule code matches, which paired backticks that bold or italics consume. code the editor styled could gain a qualifier and editor prose could stay bare. - markdown-editing-controller: _styledCodeRanges repeats the editor leftmost-rule walk and returns the code spans and fences it draws; _isInCode keeps gating link chips unchanged - compose-bar: requalification excludes those ranges - tests: composer journeys for fences, list fences, list spans, spans after bold and italics, and prose around code and list text - docs/mention-editor: unstyled markdown code forms are qualified like prose Co-authored-by: goose-wayne <ae6b377e5b6d090ee22558d19246413a5731628a127e25371111badfd4861535@buzz.block.builderlab.xyz> Signed-off-by: Kalvin Chau <[email protected]>
keeps compose_bar_widget within the mobile file size limit; behavior is unchanged. Co-authored-by: goose-wayne <ae6b377e5b6d090ee22558d19246413a5731628a127e25371111badfd4861535@buzz.block.builderlab.xyz> Signed-off-by: Kalvin Chau <[email protected]>
…icks Requalifying namesakes dropped the earlier plain binding when its only remaining occurrence sat directly against code backticks, because the occurrence matcher does not see a backtick-adjacent mention. Draft persistence still counted it, so unformatting that code later left an ambiguous unbound name. Keep the binding using persistence's presence rule. Signed-off-by: Tom Brow <[email protected]>
…esakes Requalification only knew the selected labels, so picking a second Scout also qualified the @scout prefix of a typed @scout Leader, breaking that mention and silently dropping Scout Leader from the send. Give the typed member labels the send resolves to the longest-occurrence walk, after the selected keys, so only the earlier selection's own occurrences are rewritten. The send path and requalification now share one builder. Signed-off-by: Tom Brow <[email protected]>
brow
changed the title
brow
marked this pull request as ready for review
November 13, 2026 01:58
Codex Review Summary: ✅ CompletedThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
kalvinnchau
force-pushed
the
peon/mobile-namesake-mentions
branch
from
November 13, 2026 02:31
e664a37 to
fa4032d
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #9325 namesake mention qualifying, targeting its branch. It fixes two recipient regressions in how picking a second same-name identity requalifies earlier mentions.
A binding beside code backticks was dropped. When a second namesake is picked,
_requalifyNamesakesdrops the earlier plain binding unlessrenameMentionsreports a kept occurrence. A mention sitting directly against code backticks (`@Scout`) is not an occurrence to that matcher, so the binding was removed, while draft persistence (which ignores backticks) still treats it as present. If the user then deleted the qualified prose mention and removed the code formatting, the plain@Scoutbecame an ambiguous unbound name and the send was rejected (or, with one Scout left in the roster, resolved by name to whoever that is). The fix keeps the plain binding for any renamed key that still has a plain occurrence under persistence's presence rule. Found by nettie (finding).A longer typed member name lost its prefix. The rewrite only knew the selected labels, so with members Scout, Scout and Scout Leader, picking the second Scout also qualified the
@Scoutat the start of a typed@Scout Leader. That broke the longer mention, and Scout Leader was silently dropped from the send. Requalification now also gives the typed member labels the send resolves (same candidates, no new fetch) to the longest-occurrence walk, after the selected keys, so a longer member name keeps its occurrence; only the earlier selection's own occurrences are rewritten. Found by corey (finding).The send path and requalification now share one member-candidate builder, which also keeps
compose_bar_widget.dartunder the mobile file-size limit.Validation
`@Scout`in the draft, delete the qualified prose mention, unformat, send to both.@Scout Leaderstays as typed, and all three are sent.