You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 3, 2023. It is now read-only.
Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages
Description
I'm trying out edge (586b818) since #15314 was merged. I have a command bound to alt-n (a composing diacritic in the macOS US keyboard layout) that moves the cursor. Under Atom 0.19 the keystroke would run the command and insert the diacritic. On this edge version, it only runs the command, which is awesome. 🎉
BUT, it seems like some internal buffer state then gets messed up. If after the alt-n I move the cursor with the arrows, and then insert a character, the cursor seems to jump back to where the alt-n left me, and the character gets inserted there. If I use a command that isn't a composition character, like alt-o, then the problem does not occur.
Have the cursor at the beginning of file(before F character) Type alt-n, then arrow right, then insert a character. Observe that the character is inserted at the beginning of the line (where the alt-n left you).
Repeat 2-3 using alt-o instead of alt-n. Observe the insertion happens where the cursor is, as expected.
Expected behavior: Character insertion following alt-n inserts the character where the cursor is.
Actual behavior: Character insertion following alt-n inserts the character at the wrong place (seems to be where the alt-n leaves you).
Reproduces how often: Always.
Versions
Atom : 1.21.0-dev-586b818ba
Electron: 1.6.9
Chrome : 56.0.2924.87
Node : 7.4.0
OS: macOS Sierra 10.12.6
The text was updated successfully, but these errors were encountered:
oggy
changed the title
Composition characters messing up insertion point
Composition characters mess up insertion point
Aug 16, 2017
This issue has been automatically locked since there has not been any recent activity after it was closed. If you can still reproduce this issue in Safe Mode then please open a new issue and fill out the entire issue template to ensure that we have enough information to address your issue. Thanks!
lockbot
locked and limited conversation to collaborators
Mar 31, 2018
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Prerequisites
Description
I'm trying out edge (586b818) since #15314 was merged. I have a command bound to alt-n (a composing diacritic in the macOS US keyboard layout) that moves the cursor. Under Atom 0.19 the keystroke would run the command and insert the diacritic. On this edge version, it only runs the command, which is awesome. 🎉
BUT, it seems like some internal buffer state then gets messed up. If after the alt-n I move the cursor with the arrows, and then insert a character, the cursor seems to jump back to where the alt-n left me, and the character gets inserted there. If I use a command that isn't a composition character, like
alt-o
, then the problem does not occur.Steps to Reproduce
Keymap
F
character) Typealt-n
, then arrow right, then insert a character. Observe that the character is inserted at the beginning of the line (where thealt-n
left you).alt-o
instead ofalt-n
. Observe the insertion happens where the cursor is, as expected.Expected behavior: Character insertion following
alt-n
inserts the character where the cursor is.Actual behavior: Character insertion following
alt-n
inserts the character at the wrong place (seems to be where thealt-n
leaves you).Reproduces how often: Always.
Versions
Atom : 1.21.0-dev-586b818ba
Electron: 1.6.9
Chrome : 56.0.2924.87
Node : 7.4.0
OS: macOS Sierra 10.12.6
The text was updated successfully, but these errors were encountered: