[MichaelUray]

Fixes #6925

Problem and change

Typing ':' followed by a shortcode in the chat or any text editor showed nothing; the emoji extension only converted complete :shortcode: input or pasted text, so users had to know the exact shortcode.

The emoji extension now registers a ':' suggestion based on the existing suggestion plugin used for @ mentions and / commands. Once at least two shortcode characters follow a ':' that starts a word (so times like 10:30, URLs and emoticons do not trigger it), a popup lists matching emojis, including custom ones. Arrow keys or the mouse move the selection, Enter or Tab insert the emoji, Escape or a click outside close the list. Code blocks, inline code and links are excluded.

Emoticons ending with a letter or digit (:p, :D, :o, :3, ...) were converted as soon as their last character was typed, which turned the start of most shortcode searches (:joy, :smile, :ok, :pizza) into an emoji. They are now converted only when a whitespace follows; other emoticons such as :) are still converted immediately.

Matching reuses the emoji picker rules, extracted into a pure helper in emoji-resources (search.ts) together with the suggestion ranking (exact and prefix shortcode matches first). It is exposed as the new emoji function SearchEmojis, which applies the user's skin tone. Unit tests cover the search helper and the emoticon trigger rule.

Tests

New unit tests plugins/emoji-resources/src/__tests__/search.test.ts and plugins/text-editor-resources/src/components/extension/emoticon.test.ts; test scripts added to emoji-resources. Checked manually on a self-hosted instance: typing :jo opens the suggestion list, arrow keys and hover move the highlight, Enter/Tab insert the highlighted emoji without sending the message, Esc closes only the list; :) and :p still convert; 10:30 and URLs don't open the list.

Notes

Emoticons that end with a letter or digit (:p, :D, :3 …) are now converted when a space follows instead of immediately, so they don't swallow shortcode searches like :pizza.

[ArtyomSavchenko]

@MichaelUray Please take a look at failed CI jobs:
CI / formatting (pull_request)
CI / svelte-check (pull_request)

[MichaelUray]

@ArtyomSavchenko Thanks for checking this. I investigated the latest CI run on 9d74018d; the formatting/type/unit jobs fail on missing build state, and the remaining UI failure also occurs on develop.

Here the build and all four failing jobs use the same merge, Merge 9d74018d… into e3f4f168…. There is no mixed-base formatting diff:

• build logs that merge and Cache saved with key: Linux-build-cache-build-results-a02704237fdb947ac77613bfb0e6b31cc13ef179.
• formatting logs HEAD is now at a02704237f for that merge, then Cache not found for input keys: Linux-build-cache-build-results-a02704237fdb947ac77613bfb0e6b31cc13ef179 and sh: 1: format: not found (step exit 1).
• svelte-check and test both log HEAD is now at a0270423 for that merge and the same Cache not found for input keys: build-results key, then stop at ERROR: Link flag invalid. These are cache/installation failures before the checks execute.
• uitest logs the same checkout and logs Cache restored from key: Linux-build-cache-node-platform-85c8d52495c8f987db8f51823e4115dc3c73ba8210818d148b9699f1f89f9b15 (Node dependencies). Its terminal summary is one failure: chat.spec.ts:383:7, “Checking backlinks in the Chat”, with Test timeout of 60000ms exceeded. The same test fails all three attempts in hc develop run 39878860026, at the same base e3f4f168 (job). I classify this as a known test failure on the base.

I’m preparing a separate workflow-fix PR to pin the checkouts to github.sha, make cache consumers restore-only, and rebuild on a cache miss. Re-running an old run keeps its original workflow definition and can repeat these failures.