_looks_unicode_emoji used 'len<=4 and not isascii', so a short non-ascii text label
(Sí/да/はい/café/确定) was misread as a unicode emoji and sent as a labelless component
emoji, which Discord 400s. It now treats a key as an emoji only when every codepoint is
emoji-composition material (So/Sk symbols, ZWJ, variation selectors, regional indicators,
keycap combiner) with at least one pictographic symbol - so a compound emoji (ZWJ family,
flag, skin-tone, keycap) stays one emoji while an i18n label is a label. The terminal
Discord 400 remains a documented live-gap (needs a gateway).
Signed-off-by: disqualifier <dev@disqualifier.me>
README lists BUTTON_ROW_MAX/BUTTON_LABEL_MAX/SELECT_OPTION_LABEL_MAX/SELECT_PLACEHOLDER_MAX/
SELECT_MAX_OPTIONS as flat module constants, but __init__ re-exported only the message/embed
limits, so dc.BUTTON_ROW_MAX was an AttributeError - re-export all five to match the doc.
Signed-off-by: disqualifier <dev@disqualifier.me>
When chunk_text dropped a whitespace-only content to [] and there were no embeds, the
empty-messages fallback re-sent the raw original content - the exact whitespace 444e08b
set out to eliminate, which Discord 50006s. The fallback now sends content=None so a
files/view-only call still goes out as one message, and whitespace-only content is never
forwarded raw; a genuinely empty send remains the caller's fail-loud error.
Signed-off-by: disqualifier <dev@disqualifier.me>
split_embeds chunked only by the 10-per-message count, so several individually-fitted
embeds whose combined length exceeded 6000 still 400'd (BASE_TYPE_MAX_LENGTH), breaking the
'never fails on a discord limit' contract; it now starts a new group before either the
count OR the 6000 total is exceeded. chunk_text could emit a whitespace-only piece (e.g.
'\n') when the only split boundary sat at index 1, which safe_send then sent as empty
content discord rejects (50006); whitespace-only pieces are now skipped. (live 400/50006
need discord; the split/chunk logic is verified offline.)
Signed-off-by: disqualifier <dev@disqualifier.me>
add_option(label=label, ...) passed label=None straight through for an
emoji-only key (_split_key returns (None, emoji)), serializing
{"label": null, ...} which Discord's select-option schema rejects
(1-100 char label required). The <=5-option button path is unaffected
(a button may be emoji-only). Fall back to the key's own text form
(or a single space) as the label when _split_key yields none, so the
emoji is still shown via emoji= but the option always carries a
non-empty label.
Bump 0.1.1 -> 0.1.2.
Signed-off-by: disqualifier <dev@disqualifier.me>
Fixes from the dpy4 audit report (REPORT_dpy4_audit.md, dpy_commons section):
- dpycommons-1 (HIGH): safe_send/_send applied kwargs to the first chunk only,
so allowed_mentions/silent/suppress_embeds dropped off every chunk after
the first, letting a suppressed @everyone/@here fire live on later chunks
of a mass-ping. Mention-control kwargs now apply to every chunk; file/
reference/view/etc. still ride the first message only.
- dpycommons-4 (MED): _DISCORD_HOST_RE missed discordapp.net (Discord's own
media/image CDN), causing wrap_bare_links to <>-wrap preview links Discord
itself emits; dropped the nonexistent discord.media host.
- dpycommons-8 (MED): discord_timestamp stamped naive datetimes as UTC,
diverging from discord.py's own naive-datetime handling (local via
astimezone()) and rendering the wrong wall time on non-UTC hosts. Now
matches discord.py's behavior.
- dpycommons-9: prompts.py hardcoded the 5-button/80-char/100-char limits
inline instead of sourcing from limits.py; moved them to limits.py
(BUTTON_ROW_MAX, BUTTON_LABEL_MAX, SELECT_OPTION_LABEL_MAX,
SELECT_PLACEHOLDER_MAX, SELECT_MAX_OPTIONS) and corrected the placeholder
cap from 100 to Discord's actual 150; choose() now raises ValueError above
25 options instead of failing inside discord.py's select builder.
- dpycommons-3: choose()'s select-label path now truncates labels to
SELECT_OPTION_LABEL_MAX so a >80-char key routed to the select can no
longer build a >100-char option label.
- dpycommons-7: safe_send's empty-input fallback now sends content=None
instead of content='' (Discord rejects an explicit empty string).
- redundant except: dropped discord.NotFound from parsing.py's attachment
read except tuple (it subclasses HTTPException, already caught).
- doc-only: softened chunk_text's "no content is lost" overclaim,
documented extract_message_links as guild-only (DM @me links unmatched).
Version 0.1.0 -> 0.1.1.
Signed-off-by: disqualifier <dev@disqualifier.me>
dsql