When a user entered an invalid character (whitespace or characters not
present in a name), the cleaned-up array, and hence the query,
would be empty which resulted in an error.
Fixes#17542
Previously, exact matches could be pushed off the typeahead list in the
case where there were more prefix matches that happened to rank first,
which is confusing to the user: if an emoji, for instance, falls into
this category, it will never show up in typeahead, which is easy to
confuse with the emoji not existing.
This isn't a perfect fix — there are still cases where it's hard to find
emojis because the prefix-space is very crowded, but it does fix a
category of surprising and frustrating behaviour.
This doesn't come completely without downside - it means that the exact
match emoji will jump to the front of the list, which changes what is
currently conceptually a "filtering" operation to a "filtering and
sorting" operation, but it seems on the whole to be a more ideal
experience. This is particularly notable in the non-typeahead emoji
picker, which uses the same codepath, but this change seems somewhat
desirable even there, since it allows the user to type the name of an
emoji and press enter and have that emoji show up, without having to
visually confirm that they aren't inadvertently selecting a
prefix-matching emoji.
A better solution to this in the long term might be ordering emoji
results by shortest-first as a tiebreaker for alphabetical ordering,
since that should provide the same behaviour while keeping the mental
model as "filtering" (since the sort order won't change as the user
types), but this seems like a reasonable first pass, and changing to
shortest-first ordering after making this change won't break any muscle
memory for existing users.
Concretely, we'll use this with a `UserId` type which is an
"opaque type alias" of `number` -- it's secretly implemented as
simply `number`, and it can be consumed by anything that wants a
`number` (in other words, it's a subtype of `number`), but the
fact that it secretly just is `number` is private to the module
that defines the type.
As far as the typing_status code is concerned, allowing this to
be a subtype of `number` just means that the code doesn't ever
try to inject new numbers of its own into the recipients arrays
that it passes around.
This type means that code consuming this value promises not to
mutate it. It's useful partly for the sake of simply controlling
mutation, so that arrays can be passed around without making
defensive copies; and partly because it makes the type covariant
in the elements, rather than invariant.
That is, if a function takes a plain Array<number | null>, then you
can't pass it an Array<number>, because it might add a `null` to it.
But if it takes $ReadOnlyArray<number | null>, then you can.
In general, Array<S> <: $ReadOnlyArray<S> <: $ReadOnlyArray<T>
for any S <: T, where `<:` means "is a subtype of".
Marking this type as read-only means we can pass in a read-only
array without adding a fixme (equivalent to a mypy type-ignore) to
locally disable the type-checker, nor a redundant defensive copy.
Strings should be escaped at the point of interpolation into a
template, not before. In this case, the early escape was hiding the
bug that code_language was only escaped if it was not found in
pygments_data.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Initally, when writing two or more quotes, having
a blank line in between them, merges those quotes.
This created confusion especially in "quote and reply".
This commit fixes such issues. Now two or more quotes
having a blank line in between them, will not get merged.
This change is correct both for usability and for improving our
compatibility with CommonMark.
Fixes#14379.
Upstream has slightly changed the whitespace around stashes. Take
this opportunity to clean up the extra blank lines we were outputting.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
In c563cdba61 we imported the generated
pygments data from outside `/shared` folder. This had a couple of
problems:
* Using `require` was the wrong way to do the import in ES6 modules.
* Since we get the data from outside `/shared`, clients like
zulip-mobile would not receive it - this case had to be handeled.
Here, we fix the above problems by receiving the data when initializing
through fenced_code.initialize, and when the pygments data structure is
empty (for zulip-mobile) we fallback to the old header structure without
the data-code-language tag.
Also, this commit does a small refactor to improve the way we fetch
canonicalized_alias from pygments_data.
Tests amended.
Instead of prohibiting ‘return undefined’ (#8669), we require that a
function must return an explicit value always or never. This prevents
you from forgetting to return a value in some cases. It will also be
important for TypeScript, which distinguishes between undefined and
void.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This mimics the backend logic for adding the data-attribute -
to know what Pygments language was used to highlight the code
block - in locally echoed messages.
New test added checks our logic for canonicalizing pygments alias
(for both frontend and backend).
Other fixtures and tests amended.
Since our Webpack config passes pre-minified JS files to
script-loader, they can’t be used as modules. Use the normal
unminified version, letting Webpack minify it and give us source maps.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This is a pretty straightforward conversion.
The bulk of the diff is just changing emoji.js
to ES6 syntax.
There is one little todo that can be deferred
to the next commit--we are now set up to have
markdown.js require emoji.js directly, since
it is no longer on `window`.
Zulip converts :) to the 1F642 Unicode emoji and promotes the same emoji
in the popular section of the emoji picker.
Previously Zulip has labeled 1F642 as "slight smile". While that name
conforms to the Unicode standard (which describes the code point as
SLIGHTLY SMILING FACE), it didn't match our use case of the emoji.
If a user types :) or selects the first smile in the emoji picker they
probably mean to express a regular "smile" and not a "slight smile",
which raises the question why they are only smiling slightly.
This commit relabels 1F642 as 😄 and our previous 😄 263A as
:smiling_face:. Note that 263A looks different in our three supported
emoji sets, so it is not suited to be our "default smile".
This change does not require a migration since our emoji system stores
both unicode points and names and handles name changes transparently.
Prettier would do this anyway, but it’s separated out for a more
reviewable diff. Generated by ESLint.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
We now give "slight smile" precedence over
"small airplane" if you type "sm".
More generally, we favor popularity over prefix
matches for emoji matches, as long as the popular
emoji matches on any of its pieces.
I removed a slightly confusing code comment, which I
will address in a follow up commit. Basically,
"slight smile" still doesn't win over "small airplane"
when you search for "sm", which kind of defeats the
purpose of having popular_emojis for the typeahead
use case. This is a problem with sort_emojis, though,
so when the comment was next to the list of popular
emojis, it wasn't really actionable.
Using startsWith is faster than indexOf, especially for long strings
and short prefixes. It's also a lot more readable. The only reason
we weren't using it was when a lot of the code was originally written,
it wasn't available.
This extracts get_emoji_matcher and all the
functions it depended on, most of which were
in composebox_typeahead.js.
We also move remove_diacritics out of the people
module.
This is the first major step for #13728.
This commit was originally automatically generated using `tools/lint
--only=eslint --fix`. It was then modified by tabbott to contain only
changes to a set of files that are unlikely to result in significant
merge conflicts with any open pull request, excluding about 20 files.
His plan is to merge the remaining changes with more precise care,
potentially involving merging parts of conflicting pull requests
before running the `eslint --fix` operation.
Signed-off-by: Anders Kaseorg <anders@zulipchat.com>
This feels a bit more semantically appropriate: it more clearly says
"here's some information: there is no (relevant) recipient", rather
than "no information available". (Both `null` and `undefined` in JS
can have either meaning, but `undefined` especially commonly means
the latter.)
Concretely, it ensures a bit more explicitness where the value
originates: a bare `return;` becomes `return null;`, reflecting the
fact that it is returning a quite informative value.
Also make the implementation more explicit about what's expected here,
replacing truthiness tests with `!== null`. (A bit more idiomatic
would be `!= null`, which is equivalent when the value is well-typed
and a bit more robust to ill-typing bugs. But lint complains about
that version.)
It'd already been the case for some while that calling `stop` had the
same effect as calling `update` (previously `handle_text_input`) with
a falsy recipient. With the API changes in the previous few commits,
this becomes quite natural to make explicit in the API.
aryanshridhar
Anders Kaseorg
Ganesh Pawar
Wesley Aptekar-Cassels
Greg Price
akshatdalton
Sumanth V Rao
Steve Howell
Gittenburg
Anders Kaseorg
Steve Howell