Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disconnecting and reconnecting the machine causes some diacritic entries to stop working. #1585

Open
aerickt opened this issue Jan 2, 2023 · 1 comment · May be fixed by #1663
Open

Disconnecting and reconnecting the machine causes some diacritic entries to stop working. #1585

aerickt opened this issue Jan 2, 2023 · 1 comment · May be fixed by #1663
Labels

Comments

@aerickt
Copy link

aerickt commented Jan 2, 2023

Describe the bug

Disconnecting the steno machine (tested on Gemini PR and keyboard with a Multisteno) will cause letters with diacritics to not be outputted by Plover.

To Reproduce

Steps to reproduce the behaviour:

  1. Add the following entry:
"A": "người",
  1. Writing A will output the translation as expected (người)
  2. Unplug the steno machine
  3. Plug the steno machine back in
  4. Press the "reconnect machine button"
  5. Writing A will output ngi

Additionally, trying to undo this stroke with * will still result in 6 characters being deleted.

It appears that this bug only affects previously written translation. For example, skipping step 2 in the above process won't result in the malformed translation in step 6. I'm using a Vietnamese dictionary and this also shows up there: writing words with diacritics will result in the above behaviour only if they had been written before the machine was reconnected.

Restarting Plover will fix this issue temporarily.

Operating system

  • Fedora 37 running GNOME 43.2 on x.org
  • Plover v4.0.0.dev12
@aerickt aerickt added the bug label Jan 2, 2023
@user202729
Copy link
Member

user202729 commented Jan 3, 2023

Looks like #1164 should fix it.

(my guess for what was going on: when you unplug and plug some USB device, the operating system resets the keymap, while Plover still thinks that the corresponding entries consist of the characters with diacritics that it had put in there and just reuse these slots, which obviously fails. For new entries Plover correctly "thinks" that the entries are not in the keymap, so it modifies the keymap before sending the character and the output is correct)

Cl4ryty added a commit to Cl4ryty/plover that referenced this issue Feb 18, 2024
Unplugging and then plugging in a USB device causes the operating system to reset the keymap. To avoid Plover sending key presses for keys it had previously configured but which are not mapped after the reset it is necessary to reset the keyboard emulator when resetting the machine after reconnecting so that Plover assumes the default keymap and any unmapped symbols will be added again
@Cl4ryty Cl4ryty linked a pull request Feb 18, 2024 that will close this issue
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants