Change Details

See PHI1185, which reports a performance issue with "(" in remarkup in certain contexts. I can't reproduce the performance issue, but I can reproduce the autosuggester incorrectly remaining active and swallowing return characters. When the user types `(` or `[`, we wait for a prefix for the `((` (Phurl) or `[[` (Phriction) rules. We currently continue looking for that prefix until a character is entered that explicitly interrupts the seach. For example, typing `(xxx<return>` does not insert a return character, because we're stuck on matching the prefix. Instead, as soon as the user has entered text that we know won't ever match the prefix, deactivate the autocomplete. We can slightly cheat through this by just looking for at least one character of text, since all prefixes are exactly one character long. If we eventually have some kind of `~~@(xyz)` rule we might need to add a more complicated piece of rejection logic.

See PHI1185, which reports a performance issue with "(" in remarkup in certain contexts. I can't reproduce the performance issue, but I can reproduce the autosuggester incorrectly remaining active and swallowing return characters. When the user types `(` or `[`, we wait for a prefix for the `((` (Phurl) or `[[` (Phriction) rules. We currently continue looking for that prefix until a character is entered that explicitly interrupts the search. For example, typing `(xxx<return>` does not insert a return character, because we're stuck on matching the prefix. Instead, as soon as the user has entered text that we know won't ever match the prefix, deactivate the autocomplete. We can slightly cheat through this by just looking for at least one character of text, since all prefixes are exactly one character long. If we eventually have some kind of `~~@(xyz)` rule we might need to add a more complicated piece of rejection logic.

See PHI1185, which reports a performance issue with "(" in remarkup in certain contexts. I can't reproduce the performance issue, but I can reproduce the autosuggester incorrectly remaining active and swallowing return characters. When the user types `(` or `[`, we wait for a prefix for the `((` (Phurl) or `[[` (Phriction) rules. We currently continue looking for that prefix until a character is entered that explicitly interrupts the search. For example, typing `(xxx<return>` does not insert a return character, because we're stuck on matching the prefix. Instead, as soon as the user has entered text that we know won't ever match the prefix, deactivate the autocomplete. We can slightly cheat through this by just looking for at least one character of text, since all prefixes are exactly one character long. If we eventually have some kind of `~~@(xyz)` rule we might need to add a more complicated piece of rejection logic.