Where a valid query is a string whose lowercase version
contains only ASCII lowercase letters.
@timabbott said:
>Note that the query being ascii is important
to how the comparisons are done, so that queries
with diacritics are handled properly to match
the exact diacritics used, for example.
This is a non-functional change done as a part of
a series of commits to eventually cache and use
diacritic-less full names instead of computing them
every time.
The eventual aim is to pass cached diacritic-less
full names directly to
`query_matches_string_in_order_assume_canonicalized`
when the query is plain ascii.
The name displayed for "role:members" group is
"Everyone, except guests" and "role:members" group should
be shown in the typeahead when searching for "Members" as
well, i.e. while matching the query in the input "Members"
and "Everyone, except guests" both should be considered as
display names for "role:members" group.
This commit updates the topic links obtained from clicking
the topics in the left sidebar, recent view and inbox, and
those obtained from "Copy link to topic" to use the new
topic permalinks.
Fixes part of #21505.
This commit adds typing indicators for message editing in stream
as well as in dm, if the send typing notification
for corresponding is enabled.
Based on earlier work in #28585.
Co-authored-by: Rohan Gudimetla <rohan.gudimetla07@gmail.com>
Fixes#25719.
When `sort_emojis` function was called from emoji_picker
module, the passed arguments did not contain `reaction_type`
field. As a result the first conditional of `is_popular` function
inside `sort_emojis` always failed -- hence the array
`popular_emoji_matches` was always empty`[]`. This compromised
search especially the order of filtered emojis.
Instead of checking for `reaction_type` === "unicode_emoji" -- we
check `is_realm_emoji` field is false. Since `is_realm_emoji`
field in always present and also results in easier types, this
should be prefered over adding `reaction_type` field to the passed
arguments.
Fixes zulip#30439
Updates all the https://chat.zulip.org/#narrow/stream/ links in the
docs and comments to use the new /channel/ path. All these links are
for documentation/reference purposes only and thus, can be bulk-updated.
This commit is a part of the effort to rename stream to channel.
Uptil now, the `query_matches_string_in_order` function would respect
the order of words in the query string when matching a source string.
This meant that for query "two one", the source string "one two three"
would not be matched.
For more flexibility, a new function, `query_matches_string_in_any_order`,
has been added., which returns true if each word in the query string matches
the prefix of a distinct word in the source string, else it returns false.
The algorithm for computing this is quadratic in terms of the source word
count so can be a little expensive, but it is only currently used for
searching topics in Recent Conversations, where the strings' length is
limited by the max stream / topic name length allowed, so this should be
performant enough for this use case.
This is a preparatory commit. It adds an extra notification_event_type
to the Recipient type. This can be used to differentiate between
typing notifications and message edit typing notifications since
they send different events.
So far, when ordering typeahead suggestions, any query matches that did
not occur at the start of the target string were considered equally. So
for example, for the query "ok", "squared_ok" and "smoking" were
allotted equal priority, which does not make sense.
Now, matches from a word boundary (space, hyphen, underscore or slash)
are given priority (after exact matches and beginning matches), so that
in the above example, "squared_ok" is regarded as a better match than
"smoking".
Since recipients' sorting is complex, and needs word boundary matches
separately for decoupled sorting post triage, `triage_raw` is extracted
from `triage` to return the raw matches.
Fixes: #24127.
Currently we prioritize (even partial) realm emojis above all.
Including over perfect matches if the emoji is **not** a realm emoji.
The commit changes this behavior to prioritize perfect matches above all,
regardless of emoji category.
close https://github.com/zulip/zulip/issues/27545
For the timing part of sending requests, it will be the same
as DMs, as the code in 'typing_status.ts' is being reused
for that purpose.
As a note, 'state.current_recipient_ids' and 'new_recipient_ids'
of update() in 'typing_status.ts' used to be an array of recipient ids.
Renamed them to 'state.current_recipient' and 'new_recipient' as they
can now be either of:
1) An object of format {stream_id: 2, topic:'hello'}
2) an array of recipient user IDs like previously
Also, made required changes in 'typing_status.ts' and
'typing_status.js.flow', i.e., documenting the new format of
new_recipient.
Co-authored-by: Prakhar Pratyush <prakhar841301@gmail.com>
Adds typing notification constants to the response given by
`POST /register`. Until now, these were hardcoded by clients
based on the documentation for implementing typing notifications
in the main endpoint description for `api/set-typing-status`.
This change also reflects updating the web-app frontend code
to use the new constants from the register response.
Co-authored-by: Samuel Kabuya <samuel.mwangikabuya@kibo.school>
Co-authored-by: Wilhelmina Asante <wilhelmina.asante@kibo.school>
Declares the `handler` property inside the class constructor and not
after the constructor to avoid eslint and typescript errors when we
convert this module to typescript.
Refactored `recipient` family of variables to better names like
`recipient_ids` which also aligns with the type of these variables.
Also, refactored `typing_status.test.js` to use array of user ids
instead of string names like `alice` and `bob` to stay consistent with
the actual type of these parameters.
fields set.
This commit refactors the `state` object to either be null or has all
the fields set at the same time because they are note really decoupled.
This helps us to clean our code a little bit as well as makes it easier
to migrate this module to TypeScript.
The JavaScript engine used by zulip-mobile on Android is still some
four years out of date, apparently.
This reverts commit a3d6c47b7d (#25734)
and part of commit 54f90e41c0 (#25554).
Signed-off-by: Anders Kaseorg <anders@zulip.com>
zulip-mobile currently requires Android ≥ 7 and iOS ≥ 14, both of
which support replaceAll. The code change was in commit
54f90e41c0 (#25554).
Signed-off-by: Anders Kaseorg <anders@zulip.com>
