| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
The old implementation:
- Wasn't actually checking whether handlers had been removed before
calling them.
- Could end up calling the same handler twice (if a handler was removed
further down the stack, and the stack elements moved due the resulting
splice.
Solution:
- Mark elements as removed and check. Set their ids to null.
- Don't splice stack.
Also, optimisation:
- Removing the element at the top of the stack is still O(1).
- In Modes, reverse handlers before removing (so, more likely to hit the
optimisation above).
For the record, the stable stack length at the moment seems to be about
10-12 elements.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
As a proof of concept, this incorporates normal mode, passkeys mode and
insert mode.
|
|
|
|
Previously, handlerStack was designed only for removal of the handler
right at the top of the stack. However, some handlers sought to remove
themselves when they were not at the top of the stack, creating
confusion. The new handlerStack ensures that such removal can always be
done safely.
|
