Plover as a General Chording Tool (for Zack)

[Jennifer Brien]

Zack wrote:

What would really be great is if Plover itself were a general-purpose 
chording tool, that could be easily switched between the Plover 
dictionary, Kinglet, Jackdaw, or any other chording system someone 
might implement. Something like a Plover configuration language, to 
control the various features and interpretation of strokes. 

I'm not very good with Python, so I haven't delved much into the Plover source code, but I've been having a think about this.

First. you need to be able to to associate a custom steno order and key labelling with a Plover dictionary.

That looks straightforward: its a set of characters and their associated key codes, listed in steno order. Dividers such as - are simple; they have a key code that means they are always found.

Steno order for Jackdaw (just dealing with letters for now would be  ASCTWHNR-*EOAUI-+RNLGCHTSEY

In orthographic systems such as Jackdaw, some key combinations will produce the same output no matter what other keys are in the stroke, appending it to whatever other output there is. We need a way to express that in a dictionary without needing an entry for every conceivable combination. 

I propose:  '?' means a wildcard match with anything in that part of the steno order. A stroke may match a number of entries containing ?, in which case the longest possible union of their outputs is returned. 

So the following would be Jackdaw entries: 

                "CN-?":  "z",

                "?A?":    "a",

                "?-GCT": "ch",

CNAGCT produces "zach"

                

                                                               for O would be "?-O-?": "o"

[Zack Brown]

This is definitely a good direction for Plover, but any solution
should fit with the existing dictionary format.
https://sites.google.com/site/ploverdoc/appendix-the-dictionary-format

How about "{/}" for the command, indicating that a given dictionary
entry should be treated as a sub-stroke whose interpretation will
always be constant, even when combined with other sub-strokes:

"{/}CN-": "z",
"{/}A": "a",
"{/}-GCT": "ch",

This leaves out the question of overlapping strokes. In Jackdaw, I'd
interpret the stroke "CWN" as producing either 'pz', 'zp', or 'zm',
depending on a standard rule that's part of Jackdaw. But for another
system the rule might be different. So in addition to the {/} command,
we'd need something to indicate a "relative output order". But I don't
think that would be part of the dictionary file entries, so much as
part of the definition of the custom steno order.

Be well,
Zack

> --
> You received this message because you are subscribed to the Google Groups
> "Plover" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ploversteno...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Zack Brown

[Jennifer Brien]

On Saturday, 7 May 2016 10:57:31 UTC+1, Zachary Brown wrote:

This is definitely a good direction for Plover, but any solution
should fit with the existing dictionary format.
https://sites.google.com/site/ploverdoc/appendix-the-dictionary-format

How about "{/}" for the command, indicating that a given dictionary
entry should be treated as a sub-stroke whose interpretation will
always be constant, even when combined with other sub-strokes:

                "{/}CN-":  "z",
                "{/}A":    "a",
                "{/}-GCT": "ch",

Now I'm confused. I didn't think Plover would parse commands on the left hand side of the dictionary entry. However, if that's the way to do it, it's effectively same as my ?pattern?.

 

This leaves out the question of overlapping strokes. In Jackdaw, I'd
interpret the stroke "CWN" as producing either 'pz', 'zp', or 'zm',
depending on a standard rule that's part of Jackdaw. But for another
system the rule might be different.

 

So in addition to the {/} command,
we'd need something to indicate a "relative output order". But I don't
think that would be part of the dictionary file entries, so much as
part of the definition of the custom steno order.

Well, yes, it is in the custom steno order. The rules for combining partial strokes are somewhat similar to those for combining multiple strokes in Standard Plover:

1 All the keys pressed must be accounted for, in steno order, with no gaps or overlaps.

2 A complete sequence always has precedence over two partials.

so CN-GCT produces "zck", but you could add

             "CNGCT": "Zachary Brown"

to the dictionary and then if ever you actually want "zck" you split the stroke.  

When you break the steno order up into sets of eights keys or fewer, ("in the same set" meaning not divided by a separator in the steno order) its easy to write an explicit dictionary entry for each possible combination within that set, so a partial stroke would only match with a partial stroke in other sets of keys. 

CWN on its own has no meaning in Jackdaw. I would expect the default behaviour for such combos - as in Plover, would be to print out the names of the keys in steno order.

Let's see if we can define Jackdaw's orthographic rules this way: 

 

"The + control key is normally operated by the right thumb. It doubles the first consonant of the coda. eg WINNER may be stroked WI+N|ER"

  "{/}+N":     "nn"  etc.  Few enough to explicitly enumerate, and possibly add briefs like

  "{/}+NG":  "nning"

"The * control key is normally operated, as in Plover, by the left index finger. On its own, it deletes the last stroke, as in Plover. As part of a stroke, it doubles the vowel if there only one. If there are more than one, it reverses the order of the last two, eg PARANOIA could be stroked CWAR|ANOAI*"

"{/}*A":      "aa" etc.

"{/}*OAI":    "OIA" etc.

"{/}*":         "{# Cntrl_L(BackSpace)}"  ?

"The b control key is normally operated by the right index finger. On its own, it toggles a Plover dictionary to provide briefs that are not possible in Jackdaw. As part of a stroke, it interprets that stroke only as a Plover stroke. The Jackdaw U key functions as a duplicate Plover -R so that all possible Plover strokes can be made."

This is now redundant! :)

"The E is operated by the right little finger, and the Y by the third finger. They append those letters to the coda, E preceding Y if both are present together with at least one right hand consonant, as in HONEY. Otherwise E follows Y  as in EYE or RYE" 

"{/}EY":  "ye" 

Easy enough so far :)

 

[Theodore Morin]

Benoit Pierre has been making intense efforts in a more general direction, including supporting Kinglet and Jackdaw natively, and also different layouts and orthographic systems. And he has big plans on the engine side, too, with plugin support so you can extend Plover's powers.

A lot is still in limbo and I don't want to steal his thunder, so I won't delve, but you can follow along #devtalk in the Discord room and keep an eye on Plover's GitHub Issues and Pull Requests.

--

[Zack Brown]

It's really great to see so much development happening with Plover
these days. Everyone involved is doing some really amazing work.

Be well,
Zack

--
Zack Brown

[Jennifer Brien]

I've been thinking about this some more, and l like the idea of basing orthographic rules on a Plover dictionary. That means that you do not have to change the code for adding new briefs; all that changes in the plugin is the way the dictionary is searched and how the output string is composed before it is sent to be converted into key codes.

In any orthographic system you have various sections of the keyboard that are semi - independent, each contributing a portion of the output. Steno order is a list of section names and the keys that are present in each section. If a dictionary entry contains no section names, then it is created, searched and output like any normal Plover dictionary entry. Only if none of these match are the entries with section names searched. Thus, it is always possible to make a brief using standard Plover practice.

If a dictionary entry starts with a section name then it defines what the output will be for that section - provided there is a match. The final output for the stroke is the output from all the sections, concatenated in steno order. The default output for a section which has no keys in the stroke is an empty string. Thus, Jackdaw implemented through a dictionary would have entries like:

":ONSET CTWH": "b",
":VOWEL O": "o",
":CODA GC": "b" etc.

And the stroke CTWHOGC would produce 'bob'.

So far, so unnecessary. However, consider the EY rule that I failed to get right last time:

"The E is operated by the right little finger, and the Y by the third finger. They append those letters to the coda, E preceding Y if both are present together with at least one right hand consonant, as in HONEY. Otherwise E follows Y  as in EYE or RYE" 

It's obvious that the E and Y keys should be in a different section to the rest of the coda. Here we have two conflicting rules for the same keys. The more restrictive one must be tested first, then the looser one can catch what it rejects. In this dictionary, the most recent definition always takes precedence.

The looser definition first:

":END EY": "ey"

Now for the tighter one. We need to check that there are no keys in the coda, so we do that by adding the section name to the definition, with no keys following it:

":END EY :CODA": "ye"

That's the rule in two definitions. In a similar way you could check whether particular keys are present in a different section by including them after the section name. You could have variation of syntax for anything from "all of these keys and no others" to "at least one of these keys", but so far I haven't found the need for that.

The Q rule: TNR for Q always adds a U, if followed by a vowel in the same stroke.
is simply
":ONSET TNR": "qu",
":ONSET TNR :VOWEL": "q"

On any orthographic system we need a way to indicate word boundaries. With a conventional keyboard the simplest thing is to use the space bar as normal, including it on almost every stroke.

A normal definition for the space on its own "_": " "
And included in a stroke ":BREAK _": " "

The same trick can be used for other keys which may be optionally included in a stroke whenever you have a free finger. Good candidates are initial capitalisation, ',' and '.' , and the four commonest suffixes.

The alternative way to mark word boundaries is a key that is included if only if you want to combine strokes. Including it in the leading part of a word:

":BREAK": " " ( append a space if it is not pressed)

":BREAK _": "" ( do nothing if it is)

Now we can define the Y rule:

If Y follows a right hand consonant and is followed by another stroke for a continuation of the word, then it changes to an I. Thus, BUSINESS is stroked as BUSY|NESS. but the Y in PAY|MENT does not change. 

The common case ":END Y": "y"
The common continuation ":END Y :BREAK _": "i" (or :BREAK for the space bar version)
The exception ":END Y :BREAK _ :CODA": " "y"