Use ARIA to:
+ notate that the composer has an autocomplete
+ notate the open/closed state of the autocomplete
+ notate the name of the open autocomplete options
+ notate the ID of the highlighted autocomplete option
+ improve naming of emoji autocomplete options for screen readers
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
Fixes https://github.com/vector-im/riot-web/issues/6435
This is done through an on-the-fly inverter for the settings. All the settings changed are boolean values, so this should be more than safe to just let happen throughout the SettingsStore. Typically a change like this would be done in the individual handlers (similar to how setting names are remapped to different properties or even different storage locations on the fly), however doing that for this many settings would be a huge nightmare and involve changing *all* the layers. By putting a global "invert this" flag on the setting, we can get away with doing the inversion as the last possible step during a read (or write).
To speed up calculations of the default values, we cache all the inverted values into a lookup table similar to how we represent the defaults already. Without this, the DefaultHandler would need to iterate the setting list and invert the values, slowing things down over time. We invert the value up front so we can keep the generic inversion logic without checking the level ahead of time. It is fully intended that a default value represents the new setting name, not the legacy name.
This commit also includes a debugger for settings because it was hard to visualize what the SettingsStore was doing during development. Some added information is included as it may be helpful for when someone has a problem with their settings and we need to debug it. Typically the debugger would be run in conjunction with `mxSendRageshake`: `mxSettingsStore.debugSetting('showJoinLeaves') && mxSendRageshake('Debugging showJoinLeaves setting')`.
This has been commented out for ages. Just remove it and make things
use QueryMatcher directly rather than looking like they do fuzzy matching
but not.
For example, searching for `:tong` will now match `:stuck_out_tongue` because the query `:tong` has all non-word characters removed, becoming `tong` and is then matched against the (long) names of emojis such as `smiling face with open mouth and tightly-closed eyes`.
Otherwise by default it appears first, pushing "people" further down the list
Also, remove "unicode9" category ordering, as this category does not exist as part of emojione
Which are:
- the emoji to complete is at the start of the query
- there is a whitespace character before the emoji
- there is an emoji before the emoji (so that several emoji can be input in-a-row)
Fixes https://github.com/vector-im/riot-web/issues/4498 (although it seems to be fixed through some other fix)
Plaintext emojis that start with ":" will also match against the shorthand regex but the match won't include the important part of the plaintext emoji. This means some emoji like ":)" won't be matched.
To fix this, put the ascii emoji regex first so that the match will be plaintext or otherwise it will fall through to the shorthand match (if there is one).
Fixes https://github.com/vector-im/riot-web/issues/4467
When a fully plaintext, ascii emoji is typed like ";-)", pressing tab will suggest emojione to replace it with based off of the meta data provided by emojione.
e.g. the aliases_ascii for `😃` are [":D",":-D","=D"] so typing ":D *tab*" will insert a real 😃
As of v2.7.2, fuse.js introduces a regression where the second argument to the constructor `Fuse` is assumed to be an object. There was one instance where we were not passing any argument. This fixes that.
