4 Commits (8ea5ede1dc1a76b0a53c6bd1257933d91c046a0f)

Author	SHA1	Message	Date
Strycher	ad29ea3f0e	fix(#238): Enter selects the highlighted emoji/mention in autocomplete ... The autocomplete only completed an unambiguous emoji on Enter; ambiguous queries (e.g. `:shrug` with multiple matches) sent the literal text instead of the highlighted glyph, and mentions only selected via Tab. Enter now accepts the highlighted item (emoji or mention) like Tab, then sends; Tab still selects without sending, Esc dismisses to send literal text. Removes the now-dead _emojiQuery field. (#231, emoji + mentions per Ben) Widget tests: Enter inserts the highlighted emoji (ambiguous `:shr`) and the highlighted mention (`@Bo` -> @[Bob]). Part of #231. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	1 week ago
Strycher	d39893f120	feat(#235): show the reply-to chip above a reply-gif ... A reply prepends `@[Name] `, so a reply-gif renders the gif (prior commit); this adds the `@Name` reply chip above it so it is clear the gif is a reply. Extracts TranslatedMessageContent.mentionChip + leadingReplyName (shared by inline rendering and the reply-gif header); the channel bubble builder renders the chip above the GifMessage. DMs have no reply feature, so channel-only. Part of #232. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	1 week ago
Strycher	edd9530c25	fix(#235): render inline @[Name] mention chips + reply-gifs ... Two shared-root render gaps (message tokens were only matched at fixed positions): - TranslatedMessageContent: parse @[Name] anywhere (leading, inline, or repeated) and render each as a chip; messages without a mention keep full link support (#233). - GifHelper.parseGif: strip a leading `@[Name] ` reply prefix before matching so a reply-with-gif resolves to the gif instead of literal text; arbitrary text before a gif is still left as text (#232). Tests: parseGif reply/format cases + widget tests for inline/leading/multiple mention chips. Full suite 402 green. Part of #233, #232. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	1 week ago
Strycher	d2d7930858	fix(#155): manual path entry honors the configured path-hash width ... The "Set Path" dialog parsed, built, and displayed hop prefixes as a fixed 1 byte (substring(0,2)), so on a 2-/3-byte path-hash mesh manual entry produced wrong-width routing paths and the helper text claimed "1 byte". Make it width- aware from connector.pathHashByteWidth. - parsePathPrefixes(text, width, invalid): static + testable; each entry must be EXACTLY width*2 hex chars (wrong-length / malformed go to invalid, never silently truncated); width clamped >= 1. - _updateTextFromContacts / display / maxLength group by the configured width; the display substring is guarded against short keys. - show() takes pathHashByteWidth; the chat + path-management callers pass connector.pathHashByteWidth. - l10n: reworded the path-entry helper / example / instructions to be width- agnostic (dropped the "2 hex / 1 byte / first byte" claims). The 17 non-English locales keep their prior strings, flagged for re-translation (English fixed). analyze clean; 6 parsePathPrefixes tests (incl. exact-length + clamp). Gemini v1 BLOCKER (unguarded substring) + MAJOR (silent truncation) fixed; v2 MAJORs were the pre-existing refresh button (out of scope), v2 MINOR (1-byte example) fixed. Closes #155 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2 weeks ago