If someone's really interested in doing this, I think the Moonlander (https://www.zsa.io/moonlander) keyboard has a stenography mode
It always looks so fascinating to see someone type at like 350 WPM but that's not me.
Somewhat hilariously, having perused your first two links, and followed the link from Sweep to Ferris, I still find myself having no idea how any of this works. (But I know a lot about how the firmware and PCB layout is designed!).
I have a charachorder. It's similar to music theory where you can hit individual notes to make up a chord. With chording you hit multiple keys usually that are part of a larger word and it outputs the associated word. This means instead of having to hit every individual key in sequence to type out a phrase one character at a time, you hit multiple keys at once to output words at a time. In the time it takes to output a single character on a keyboard someone on a charachorder did the entire word already. The longer the word the more speed is gained from this. It takes a lot of time to learn though, like a solid month of practice just to get near speeds I have with normal keyboard. Significantly helps with hand strain from typing all day due to requiring far less hand movement.
It’s awesome just how fast and accurate they can be, and most devs were of my mindset “wow can I learn to type like that - it woukd solve this problem and that”
Till we found out just how much work is needed to get good. It’s a true skill, and sadly undervalued but something that just has too little pro for the cons - in my opinion as a developer.
I already type at faster than I can code, and slightly slower than I can write English. A better keyboard, or the same keyboard at different workstations and laptops, or some typing tutorials woukd help me - but full on 100wpm is not going to help me debug Kerberos failures
This is interesting. I haven't watched the whole talk so please ignore this if it's discussed there. The Steno keyboard looks like it takes into consideration that the language being typed is English (syllable split etc.) so if you're typing a programming language with variable names that have non english spellings, wouldn't it be a problem?
I've been trying to learn steno on and off for 5+ years. The problem is I already have 150 WPM on qwerty and I cannot think of a message on Teams faster than I currently type. The opportunity cost is far too large to justify unless you need to transcribe someone else's speech.
I top out around 100 wpm but still rarely bother to push myself to hit my max—and pretty much never when writing code.
I can’t really relate to “I need to type faster!” programmer optimizations, nor complaints about things like static typing slowing people down because it’s a few more characters (more thinking, I’d get, but some folks do seem bothered by the extra keystrokes) since input speed is nowhere near being my bottleneck when I’m writing code.
I suppose there must be people out there who simply think a ton faster than me, and of course some others are much slower typists than me, and for those folks that stuff’s a bigger deal.
I also see no need to type faster, but as I get older and have more and more RSI-type issues I'm starting to see more and more appeal into being able to type at the same speed with fewer keystrokes.
Always seemed to me like they'd be terrible for programming with all the punctuation though.
I also need a mouse way too much (and I have shakey hands so trackballs/nipple mice are not viable)
I was never trained as a touch-typist. I still have to look at the keyboard as I type, and have never become a master CLI maven.
But it hasn’t prevented me from writing thousands of pages of prose, and millions of lines of code.
I think it has probably also saved me from RSI. I have a friend that is a master engineer, that has to change their career, because their arms are all screwed up (multiple surgeries didn’t fix it).
It was interesting and fun but I didn’t have enough time/patience to get really good at it.
To get good requires both a lot of practice and building up a personal dictionary. Also steno itself is more adapted for transcribing speech than code, which uses symbols and special characters a lot.
In my experience, typing speed is never the issue. I've worked with truly 10x and better programmers in my life and the road block for even them is thinking not typing.
Raw typing speed is not a blocker to being a good programmer. However, I've generally found that if someone types fast (and uses shortcuts especially in his editor), it usually a sign that he's done a lot of it and that has proven to be a decent proxy for coding experience. This is specifically for junior developers.
The real argument for using stenotype keyboards for coding is not typing speed, it's avoiding RSI. On a stenotype keyboard you "type" chords by pushing down with your arms, not your fingers - it's a bit like playing an organ, or a synth keyboard. You don't hear about many organists getting RSI (though some piano players do). The fingers also just move a lot less, much of the "moving" to different keys is also done with the arm muscles.
I agree w/ others in this thread about the underlying challenges for using a steno keyboard for coding. You basically need to pick a custom chord for every program identifier, keyword or symbol, and somehow make those chords memorable. Perhaps a custom IDE featureset can help, leveraging the LSP or tree-sitter parsers?
Speed is not all that important but being able to reliably touch type is. The translation from the mental to the screen should be done with a minimum of conscious thought as that detracts from thinking about the code.
To the extent it's important at all it's a matter of removing mental load. Anything you have thought of but not yet put on the screen is load.
It's not a roadblock, but it is an issue since faster typing leaves you with more time for thinking, but also has can have an important side-benefit of not breaking flow if you're not distracted for long
> In my experience, typing speed is never the issue. I've worked with truly 10x and better programmers in my life and the road block for even them is thinking not typing.
Thinking is a lot easier when your output is seamless and reliable though. Nothing sucks more than debugging typos. The code should work, but it doesn’t. You know you did everything right, but it just won’t work.
20min later … oh wait it’s a typo. Fix was perfect just mangled between brain and keyboard.
Double bad when for whatever reason you can only debug on a remote environment and every iteration takes several minutes.
Learn to type fast and reliably. It’s easily one of the highest ROI things I ever did.
IANACR, but I would think it's not practical, in that the stenotype keyboard (the official term for the keyboard used by court reporters) is used to record the phonetic _sounds_ of what is being spoken, rather than the actual words. These phonetic codes do not resemble anything approximating the actual words they represent.
Also, computer source code (whatever the language) typically contains variable names which often are (a) typically case-sensitive, and (b) abbreviated or even single characters. And even the basic syntax of the chosen language may not be easily capturable via phonetic sounds, what with open and closing parentheses, curly braces, square brackets, etc., and compound reserved words with prefixes (such as #foreach in Velocity template language).
Again, IANACR, but I don't see how it could possibly work...
I seem to remember reading once that what is typed by a stenographer is also only meaningful to them. And therefore must be transcribed into English later by the same stenographer.
What stenographers capture is phonetic. These days a computer program translates that back into written language in real time. It uses knowledge of the language to pull this off. So it's a bit like autocorrect on you phone.
That used to be true but it's much more automatic now that the process involves a computer translating into English in real-time (it's no longer a stenographer translating from their notes by hand).
I wonder how far programming-specific chorded keyboards could get. Like you usually only have a handful of variables in a function or method. I bet, at least, all the extra context provided by object oriented languages could be used to help the keyboard provide us meaningful suggestions.
Depends on your goal. Chording technique is superior when typing words contained in the dictionary. Meaning that typing some rarely used word required typing it multiple times to "confirm".
Writing code does not suite well for this, since coding with completion contains much more punctuation than plain text.
Instead, check out ergonomic mechanical keyboards: low-profile, split, with columnar stagger, preferrably with 36 or less keys. Uncommon keys are behind a modifier key that acts as a normal key when pressed, but as a layer when held (called modtap).
Also you can experiment with non-qwerty layouts, but IME it gives much less benefit than having a layered layout of physical keys.
Non-qwerty seems to me to be one of the biggest wastes of time we’ve come up with in search of productivity. The time spent learning it could be spent learning vi, learning Haskell, learning to shoot hoops or learning the guitar. Pretty much all of those would benefit you more.
Good point - I bet completions are much quicker in practice than a chord for commonly used snippets. At least the number of chords a normal human can remember!
This. Using QUERTY immediately feels uncomfortable when i have to use it. Learned NEO2 which has layers accessed with modifier keys. Having a numpad under your hand is one of its' many advantages.
Dvorak keyboard's fatal flaw is when you have to type on someone else's keyboard. Standardization has its benefits, even if less than ideal. Trackballs have a similar issue.
A lot of the people customizing layouts for the Twiddler chording keyboard (https://www.tekgear.com/keyboards.html) are programmers, and are building custom layouts that reflect this.
I have one that I bought, it is mechanical and has a 3 or 4 inch wide paper tape, but, it ALSO has a 9 pin serial port and can be driven by Plover (mentioned elsewhere on this thread) I believe. Haven't yet wired it up yet as it is in storage.
I wish Plover supported Wayland.. it looks like a lot of work from lots of different people went into different workarounds but nothing that managed to end up in a mergeable state as yet
Humor on HN is generally accepted if it's clever or makes you think in some way. But "haha some words have multiple meanings!" doesn't quite meet that bar.
>Humor on HN is generally accepted if it's clever or makes you think in some way.
generally, eh?
faa--aa--aa--aa--ukk.
I don't know whether to laugh or cry at the ridiculousness of that statement. overall, to laugh, I think, makes more sense. because, according to you, majority wins?
that means minorities should not have any voice? their voices should be suppressed by downvoting or criticizing them for not toeing the "generally" (sheesh!) accepted line?
then how is this different from any other form of discrimination, such as racism, sexism or ageism?
can we call it old-boys-club-ism?
you miserably fail to convince, right at your first sentence above, bro. but that's par for the course for the many HNers of the hive mind / echo chamber kind, who think that everyone else needs to think like them, or else they are considered the wrong type of people, and try to brain wash them into thinking differently from what they already do, as you just tried to do above, or by knee-jerk reflex action, downvote them. I have seen that pattern often on this site. and it's not just me, others have commented about it too.
because, you know, generally, it is considered that people should be tolerant of others' opinions, unless they are dangerous or something like that. and how is making a few innocuous puns, even if they are not "clever", dangerous?
I bet you don't agree with that statement.
but, and this is my key point, by the way, did you see what I did there with my use of the word generally?
I used it in the same discriminatory way as you did.
still editing, to make any wording changes and check for typos.
From what I understand, stenography adopts a keyboard to a language allowing a person to type multiple keys at the same time to write a "code" that can be translated to English.
Programming languages don't have such constraints because the language can be fluid to adopt to the keyboard. A good example is C compared to the much less terse Delphi.
I don't think that's true. You've probably had moments when you had the entire design of a program in your head, and it required typing out hundreds of lines, or even thousands, all of them mostly conforming to the original idea.
Sometimes, and more so in certain languages and the way they are used, massive amounts of boiler plate are required. Programmers use copy and paste techniques to do this, which are basically devices for massively amplifying typing speed and accuracy. When you copy 50 lines, and then change five places in the copy, that's faster than typing them from scratch. The editing commands are a kind of shorthand, which gets expanded in the editing buffer.
This doesn’t really answer your question but I was on Jury Duty recently and was disappointed to learn that the stenographer was using a normal QWERTY keyboard and boring Dell computer. It seems that they used special software however that was connected to an audio feed with some recall ability.
That being said there is some [support for stenography in the QMK programmable keyboard firmware](https://docs.qmk.fm/features/stenography). I’m not sure how widespread its use is.
If someone's really interested in doing this, I think the Moonlander (https://www.zsa.io/moonlander) keyboard has a stenography mode It always looks so fascinating to see someone type at like 350 WPM but that's not me.
The special phrase you want is "chord"
A stenographer's keyboard is a special kind of chord keyboard for spoken English.
There are other kinds of chord keyboards, but look into those.
For example:
- https://www.charachorder.com/
- https://github.com/davidphilipbarr/Sweep
Related:
https://news.ycombinator.com/item?id=30515912
Somewhat hilariously, having perused your first two links, and followed the link from Sweep to Ferris, I still find myself having no idea how any of this works. (But I know a lot about how the firmware and PCB layout is designed!).
I have a charachorder. It's similar to music theory where you can hit individual notes to make up a chord. With chording you hit multiple keys usually that are part of a larger word and it outputs the associated word. This means instead of having to hit every individual key in sequence to type out a phrase one character at a time, you hit multiple keys at once to output words at a time. In the time it takes to output a single character on a keyboard someone on a charachorder did the entire word already. The longer the word the more speed is gained from this. It takes a lot of time to learn though, like a solid month of practice just to get near speeds I have with normal keyboard. Significantly helps with hand strain from typing all day due to requiring far less hand movement.
If anyone is interested in a fun chording layout, check out ASETNIOP. It’s surprisingly easy to use.
Preordered https://forgekeyboard.com/
We'll see if I can actually use it!
A while back in PyCon UK I met some of the people behind http://www.openstenoproject.org/plover/
It’s awesome just how fast and accurate they can be, and most devs were of my mindset “wow can I learn to type like that - it woukd solve this problem and that”
Till we found out just how much work is needed to get good. It’s a true skill, and sadly undervalued but something that just has too little pro for the cons - in my opinion as a developer.
I already type at faster than I can code, and slightly slower than I can write English. A better keyboard, or the same keyboard at different workstations and laptops, or some typing tutorials woukd help me - but full on 100wpm is not going to help me debug Kerberos failures
This is interesting. I haven't watched the whole talk so please ignore this if it's discussed there. The Steno keyboard looks like it takes into consideration that the language being typed is English (syllable split etc.) so if you're typing a programming language with variable names that have non english spellings, wouldn't it be a problem?
Steno will get you to 200+ wpm, not 100.
I've been trying to learn steno on and off for 5+ years. The problem is I already have 150 WPM on qwerty and I cannot think of a message on Teams faster than I currently type. The opportunity cost is far too large to justify unless you need to transcribe someone else's speech.
I top out around 100 wpm but still rarely bother to push myself to hit my max—and pretty much never when writing code.
I can’t really relate to “I need to type faster!” programmer optimizations, nor complaints about things like static typing slowing people down because it’s a few more characters (more thinking, I’d get, but some folks do seem bothered by the extra keystrokes) since input speed is nowhere near being my bottleneck when I’m writing code.
I suppose there must be people out there who simply think a ton faster than me, and of course some others are much slower typists than me, and for those folks that stuff’s a bigger deal.
I also see no need to type faster, but as I get older and have more and more RSI-type issues I'm starting to see more and more appeal into being able to type at the same speed with fewer keystrokes.
Always seemed to me like they'd be terrible for programming with all the punctuation though.
I also need a mouse way too much (and I have shakey hands so trackballs/nipple mice are not viable)
I was never trained as a touch-typist. I still have to look at the keyboard as I type, and have never become a master CLI maven.
But it hasn’t prevented me from writing thousands of pages of prose, and millions of lines of code.
I think it has probably also saved me from RSI. I have a friend that is a master engineer, that has to change their career, because their arms are all screwed up (multiple surgeries didn’t fix it).
Yes:
https://www.fortressofdoors.com/stenography-for-programming/...
It was interesting and fun but I didn’t have enough time/patience to get really good at it.
To get good requires both a lot of practice and building up a personal dictionary. Also steno itself is more adapted for transcribing speech than code, which uses symbols and special characters a lot.
In my experience, typing speed is never the issue. I've worked with truly 10x and better programmers in my life and the road block for even them is thinking not typing.
Raw typing speed is not a blocker to being a good programmer. However, I've generally found that if someone types fast (and uses shortcuts especially in his editor), it usually a sign that he's done a lot of it and that has proven to be a decent proxy for coding experience. This is specifically for junior developers.
The real argument for using stenotype keyboards for coding is not typing speed, it's avoiding RSI. On a stenotype keyboard you "type" chords by pushing down with your arms, not your fingers - it's a bit like playing an organ, or a synth keyboard. You don't hear about many organists getting RSI (though some piano players do). The fingers also just move a lot less, much of the "moving" to different keys is also done with the arm muscles.
I agree w/ others in this thread about the underlying challenges for using a steno keyboard for coding. You basically need to pick a custom chord for every program identifier, keyword or symbol, and somehow make those chords memorable. Perhaps a custom IDE featureset can help, leveraging the LSP or tree-sitter parsers?
Speed is not all that important but being able to reliably touch type is. The translation from the mental to the screen should be done with a minimum of conscious thought as that detracts from thinking about the code.
To the extent it's important at all it's a matter of removing mental load. Anything you have thought of but not yet put on the screen is load.
It's not a roadblock, but it is an issue since faster typing leaves you with more time for thinking, but also has can have an important side-benefit of not breaking flow if you're not distracted for long
Ironically writing less code is probably better!
Nah, that's not ironic.
What would be ironic is getting RSI after you chose to write less code in order to avoid getting RSI.
This is true.
I always say that the best code I write, is the code I don’t write.
> In my experience, typing speed is never the issue. I've worked with truly 10x and better programmers in my life and the road block for even them is thinking not typing.
Thinking is a lot easier when your output is seamless and reliable though. Nothing sucks more than debugging typos. The code should work, but it doesn’t. You know you did everything right, but it just won’t work.
20min later … oh wait it’s a typo. Fix was perfect just mangled between brain and keyboard.
Double bad when for whatever reason you can only debug on a remote environment and every iteration takes several minutes.
Learn to type fast and reliably. It’s easily one of the highest ROI things I ever did.
Mentioned by others, but I like project pages or home git repositories.
https://github.com/openstenoproject/plover
https://www.openstenoproject.org/plover/
An in-browser demo, https://www.openstenoproject.org/demo/
Suggested, loved extensions, https://github.com/openstenoproject/awesome-plover
Chorded keyboard input methods, more generally, are worth looking into.
IANACR, but I would think it's not practical, in that the stenotype keyboard (the official term for the keyboard used by court reporters) is used to record the phonetic _sounds_ of what is being spoken, rather than the actual words. These phonetic codes do not resemble anything approximating the actual words they represent.
Also, computer source code (whatever the language) typically contains variable names which often are (a) typically case-sensitive, and (b) abbreviated or even single characters. And even the basic syntax of the chosen language may not be easily capturable via phonetic sounds, what with open and closing parentheses, curly braces, square brackets, etc., and compound reserved words with prefixes (such as #foreach in Velocity template language).
Again, IANACR, but I don't see how it could possibly work...
I seem to remember reading once that what is typed by a stenographer is also only meaningful to them. And therefore must be transcribed into English later by the same stenographer.
Can anyone here confirm that?
What stenographers capture is phonetic. These days a computer program translates that back into written language in real time. It uses knowledge of the language to pull this off. So it's a bit like autocorrect on you phone.
That used to be true but it's much more automatic now that the process involves a computer translating into English in real-time (it's no longer a stenographer translating from their notes by hand).
I wonder how far programming-specific chorded keyboards could get. Like you usually only have a handful of variables in a function or method. I bet, at least, all the extra context provided by object oriented languages could be used to help the keyboard provide us meaningful suggestions.
Depends on your goal. Chording technique is superior when typing words contained in the dictionary. Meaning that typing some rarely used word required typing it multiple times to "confirm".
Writing code does not suite well for this, since coding with completion contains much more punctuation than plain text.
Instead, check out ergonomic mechanical keyboards: low-profile, split, with columnar stagger, preferrably with 36 or less keys. Uncommon keys are behind a modifier key that acts as a normal key when pressed, but as a layer when held (called modtap).
Also you can experiment with non-qwerty layouts, but IME it gives much less benefit than having a layered layout of physical keys.
More info here: https://www.reddit.com/r/ErgoMechKeyboards/
Non-qwerty seems to me to be one of the biggest wastes of time we’ve come up with in search of productivity. The time spent learning it could be spent learning vi, learning Haskell, learning to shoot hoops or learning the guitar. Pretty much all of those would benefit you more.
For some it's not about productivity, but about getting a few more years out of your fragile body before RSI ends your career.
Same reason voice recognition isn't good for code.
AFIAK all writing-compression methods come down to optimizing for the common--and so much of what we do is the uncommon. We need lots of keys.
Couldn’t you just create new chords that represent the most commonly typed code components?
Yes, but people who use an IDE will already have support for “code snippets” and completions, so you need to look for a different advantage to create.
Good point - I bet completions are much quicker in practice than a chord for commonly used snippets. At least the number of chords a normal human can remember!
I can already type on a QWERTY keyboard way faster than I can think.
That's one reason I haven't adopted a Dvorak habit.
Most court reporters use software nowadays that renders their special stenotype skills obsolete.
> Most court reporters use software nowadays that renders their special stenotype skills obsolete.
What software?
It would need text-to-speech of the same accuracy; for that to be possible (how accurate is that?) I think everyone would have to be properly mic'd.
Also, TTS errors would need to be detectable somehow by the stenographer, or transcripts could go dreadfully wrong.
Dvorak is much more comfortable than qwerty, in my opinion. I never actually cared about speed, it just feels better.
This. Using QUERTY immediately feels uncomfortable when i have to use it. Learned NEO2 which has layers accessed with modifier keys. Having a numpad under your hand is one of its' many advantages.
Dvorak keyboard's fatal flaw is when you have to type on someone else's keyboard. Standardization has its benefits, even if less than ideal. Trackballs have a similar issue.
It's more about comfort than speed.
Can you give some names/information on the software that is used ?
Absolutely yes, but not me personally. The keywords to search for are Plover, Stenotype https://youtu.be/jRFKZGWrmrM
Charles Moore, creator of the FORTH programming language, also created a one-hand "puck" keyboard that worked by chording.
Supposedly, he used it to write programs in FORTH while driving to work.
As far as the story goes, he programmed input-only, having no visual or audible way to review what he wrote.
"...and back in the day, we had to chip the edges of zeroes to make ones..."
A lot of the people customizing layouts for the Twiddler chording keyboard (https://www.tekgear.com/keyboards.html) are programmers, and are building custom layouts that reflect this.
This guy on YouTube talks about his experience using a steno keyboard and Plover for writing code.
https://youtube.com/@aericksteno
and https://www.youtube.com/watch?v=jRFKZGWrmrM
I have one that I bought, it is mechanical and has a 3 or 4 inch wide paper tape, but, it ALSO has a 9 pin serial port and can be driven by Plover (mentioned elsewhere on this thread) I believe. Haven't yet wired it up yet as it is in storage.
Feel it would be interesting trying a chording keyboard with a glyph based language - thinking APL, BQN and the like…
There you could match the chords to glyphs rather than require the auto complete functionality others have suggested.
You might consider using a templating system similar to `yasnippet` to expand abbreviations.
https://github.com/joaotavora/yasnippet
Here is a great video on how the stenotype keyboard works and how words and sentences are represented: https://m.youtube.com/watch?v=OPZW8prlEYE
It's not a general purpose character entry method, but it's very interesting.
I wish Plover supported Wayland.. it looks like a lot of work from lots of different people went into different workarounds but nothing that managed to end up in a mergeable state as yet
The ideal amount of code you should write to solve a problem is none, but I'm sure it's been tried to antisocial results.
Yes, I doubt the people paying you to write code will find that argument very convincing...
...are people actually paid to write code? It's a means not an end!
Not me. I gave it a trial, but couldn't do justice to it. The key jurors got bored of the case. So I couldn't write a sentence.
Downvoted for a good pun!
The HNHEF (HN Humor Eradication Force), like the oft-mentioned-on-HN RESF (Rust Evangelism Strike Force), strikes again!
Foo(l)ray!
Humor on HN is generally accepted if it's clever or makes you think in some way. But "haha some words have multiple meanings!" doesn't quite meet that bar.
>Humor on HN is generally accepted if it's clever or makes you think in some way.
generally, eh?
faa--aa--aa--aa--ukk.
I don't know whether to laugh or cry at the ridiculousness of that statement. overall, to laugh, I think, makes more sense. because, according to you, majority wins?
see https://simple.m.wikipedia.org/wiki/Majority_rule
and the downsides mentioned there.
that means minorities should not have any voice? their voices should be suppressed by downvoting or criticizing them for not toeing the "generally" (sheesh!) accepted line?
then how is this different from any other form of discrimination, such as racism, sexism or ageism?
can we call it old-boys-club-ism?
you miserably fail to convince, right at your first sentence above, bro. but that's par for the course for the many HNers of the hive mind / echo chamber kind, who think that everyone else needs to think like them, or else they are considered the wrong type of people, and try to brain wash them into thinking differently from what they already do, as you just tried to do above, or by knee-jerk reflex action, downvote them. I have seen that pattern often on this site. and it's not just me, others have commented about it too.
because, you know, generally, it is considered that people should be tolerant of others' opinions, unless they are dangerous or something like that. and how is making a few innocuous puns, even if they are not "clever", dangerous?
I bet you don't agree with that statement.
but, and this is my key point, by the way, did you see what I did there with my use of the word generally?
I used it in the same discriminatory way as you did.
still editing, to make any wording changes and check for typos.
From what I understand, stenography adopts a keyboard to a language allowing a person to type multiple keys at the same time to write a "code" that can be translated to English.
Programming languages don't have such constraints because the language can be fluid to adopt to the keyboard. A good example is C compared to the much less terse Delphi.
For programming, querty-typing speed is not really a bottleneck for me. I already don't think as fast as I type.
I would like to be able to take notes as fast as people are talking, though, and for that you do need a chording keyboard.
I don't think that's true. You've probably had moments when you had the entire design of a program in your head, and it required typing out hundreds of lines, or even thousands, all of them mostly conforming to the original idea.
Sometimes, and more so in certain languages and the way they are used, massive amounts of boiler plate are required. Programmers use copy and paste techniques to do this, which are basically devices for massively amplifying typing speed and accuracy. When you copy 50 lines, and then change five places in the copy, that's faster than typing them from scratch. The editing commands are a kind of shorthand, which gets expanded in the editing buffer.
This doesn’t really answer your question but I was on Jury Duty recently and was disappointed to learn that the stenographer was using a normal QWERTY keyboard and boring Dell computer. It seems that they used special software however that was connected to an audio feed with some recall ability.
That being said there is some [support for stenography in the QMK programmable keyboard firmware](https://docs.qmk.fm/features/stenography). I’m not sure how widespread its use is.