Baffling Scrivener + Steno Bug

Hi. You probably don’t get many stenographers writing in Scrivener,
but something HORRENDOUSLY WEIRD just happened, and I have no idea how
to fix it.

Okay, so I’m using an open source steno engine called Plover with a
steno machine connected via Bluetooth. It’s basically a qwerty
keyboard emulator; I write steno code, it gets sent through a JSON
file that matches it with its English translation, and then the
English is transmitted as simulated keystrokes into the active window.
It’s basically a qwerty emulator. I use this setup professionally,
usually to write into Vim. I often write for 8 hours a day with this
system and have had absolutely zero problems or bugs with it. It’s
rock solid. Up 'til now, the same was true with Plover writing into
Scrivener! I wrote about 11,000 words in my NaNoWriMo project, plus a
month of daily prep in October, with everything working absolutely

But today I was scanning through my document and I decided scrolling
up with just the up arrow command was too slow, so I made a steno
definition for “Page Up”, except instead of defining it as {#Page_Up},
I accidentally defined it as {#PageUp}. That shouldn’t matter; Plover
would just output that in characters instead of as a command, and then
I’d realize my mistake and redefine it. So I made the mistake, saw the
letters show up in the text of Scrivener, realized my mistake,
redefined it – no problem.

Except immediately after that, Scrivener stopped accepting the capital
letters A, C, D, G, H, P, S, and T when entered with my steno machine
– but only in the body of Scrivener texts! It still works when I
enter the alphabet with my qwerty keyboard, and it still works when I
write with my steno machine in the Inspector Notes.

When I try to write the capital alphabet with my steno machine, this
is what I get:


The second complete capital alphabet is what I get when I write with
qwerty in Scrivener’s body text or if I write with steno in the
Inspector or in any other program, including Vim, Google Docs, and
Microsoft Word. Nothing else seems to be working anomalously, and now
that I’ve redefined the original entry as Page_Up, that’s working
perfectly as well.

I know it seems bizarre, but I swear this is what’s happening. I’ve
tried dozens of times and the same behavior is seen every single time.
If you don’t believe me, I’ll make a screencast.

What is going on??!?!?

I have never seen an error like this in my life, and I’m completely at
a loss to explain it. I’ve shut down and rebooted the computer; no
change. I’ve made a new blank Scrivener file; no change. I’ve
eliminated all autocorrections from the “Corrections” menu.

If I can’t correct this problem, it’ll make Scrivener completely
unusable and I’ll have to start over in another platform for the rest
of NaNo. Do you have any idea what’s happening or how to fix it?


By the way, I’ve tried it with different fonts and I’ve tried turning invisible characters on. No change. I’m completely baffled. Just wrote for an hour in Vim with zero problems, so I’m quite sure it’s specific to Scrivener.

Do you think if I exported my project (with notes, research, outline, and manuscript), uninstalled and reinstalled Scrivener, and then imported it again, it would reset whatever inexplicable thing was changed?

Just one more thing. It suppresses these letters no matter how I arrive at them. I can explicitly make a capital S with S*P. That’s suppressed. Plover will autocapitalize an S after a period. That’s suppressed. Names can be defined with a capital S. That’s suppressed. “I’m going to Sam’s house” comes out “I’m going to am’s house.” Or I can manually invoke the “capitalize next” flag. That’s suppressed. I’m stumped.

I wouldn’t think that would make much of a different here as this problem seems to be very predictable. You do this action with the page up command, and after that point not all of character entry functions as expected, correct? I’m assuming after restarting the software it goes back to working fine until you use page up again?

If you do wish to try reinstalling though, there would be absolutely no need to export everything to files when reinstalling. Phones might work that way but computers have always used a very sharp distinction between software and data. How Scrivener projects are worked with is explained in the user manual in, Chapter 7.

As for what is going on, I would test in any other Qt-based program given that is what Scrivener is written with. I would test with LyX and see if you get a similar problem in a test document. That may not be a perfect example though, as we are using the older Qt4 framework and I’m not sure what the LyX team is using. We are in the process of updating to QT5 though.

What some people do, if they have problems with full text editor control via an alternate input device, will write into another window (such as Vim) and then copy and paste into Scrivener when done.

No, that’s the weird thing! It doesn’t work fine. It seems like it’s just permanently screwed up. Every time I restart Scrivener now, it suppresses those capital letters, whether or not I send the PageUp command.

The same problem occurs with a few other tools–some cases of rich text expansions in PhraseExpress, and one user encountered it with MyScript Stylus. It seems to be a problem with how Scrivener’s Qt framework is handling the text entry from these sources, but we haven’t found a fix. Does Plover work in plain-text? With PhraseExpress, the plain text expansions didn’t suffer this problem, so if there are settings of that sort which you could play with in Plover, it might help.

What’s most curious is that you were working successfully with this setup until the page up command error. Did anything else change when you made the correction?

That’s the thing. Plover is essentially just outputting plain text. And I had zero problems with it until today. It’s like a switch flipped or something. And why should it still work normally in the notes field of the Inspector?

There are some times on my PC when, for some reason, Windows thinks the Windows or the Alt key got “stuck” - so I’ll be typing something, and when I press “e”, an Explorer window will appear.

I wonder if something similar is happening - some command sent or a key state (Shift, Ctrl, Alt, or Windows) sent an “on” command but not the “off” command, and the key combination would work in the rich text editor, but not in the text-only fields. I am not sure I see a pattern to the keys with the problem, which seem to be ACDGHPST.

When this problem happens to me, just mashing all of those keys (Shift, Ctrl, Alt, and Windows) a bunch of times seems to “clear” the issue.

It doesn’t exactly fit the scenario necessarily, but maybe it’s a similar issue happening?

I’ve uninstalled and reinstalled Scrivener. I’ve uninstalled and reinstalled Plover. I’ve set up a new user in Windows and tried to start from scratch. The problem is still happening.

Like, I’ll write SKWR in Plover, and the Plover note output will read “SKWR”. In the Inspector, it’ll come out “SKWR”. But in the body, it’ll come out KWR, even though the Plover note output (which echoes the notes it’s sending out to the OS) is still reading SKWR. Every time. And no other program is showing me this error. I’m stumped.

Plover’s lead dev gave me a new experimental build that outputs text in a slightly different way… And whatever change it contained, Scrivener suddenly works properly again! HALLELUJAH!!!

Oh, great news! Any chance we could get details on the changes they made to their output? I don’t know if it would help, but I’d love if we could find a way to work around the problem on our end while we’re still using this version of the Qt framework.

Not really relevant now, but re: the bug only affecting the main editor and not the document notes, this isn’t really as odd as it seems because they don’t use all the same code behind the scenes. The main editor is much more complex than the document notes and supports features like auto-correction, auto-completion, additional formatting, etc. Unfortunately in this case it also means a greater chance of weird bugs.