Add Context Chording

[Danc2050]

PROBLEM & PROPOSED THEORY/SOLUTION
If I want to have simple chords, like ear and I have another chord aer (a root of the English language), their chords collide with one another . This is because we are using one database for all chords. There is no way around this (except having another dictionary), but we can mitigate the effect when typing whole words (made up of chords + character entry) by creating a context mode/feature when chording.

GENERAL EXAMPLE
Take for example the word aerospace. A person may chord + character entry something like: aer + o + space. However, one can't do that if they have the chord ear in their dictionary.

LOGIC

1. If a user chords a chord (e.g., aer) and it has no anagram in the chord database, then we output it immediately.
2. However, if a user has a potential conflict/anagram in the chord database, we can output the first chord it matches on (e.g., ear) and then start observing the user's input to make a change to that chord based on context.
3. The observer/zipchorder builds a list of chords that are anagrams and builds a string out of each potential match that crosschecks a dictionary of words (e.g., English dictionary)

CONCRETE EXAMPLE
To summarize, we need 2 text documents: 1) a dictionary of chords 2) a dictionary of words that we would chord with (e.g., the english language dictionary). Here are the chords:

ear -> ear // when mashed together conflicts with `aer` chord
aer -> aer // when mashed together conflicts with `ear` chord
space -> space // why not

And our English dictionary:

aerospace: that thing in space...
ear: that thing on your head
aer: that part of a word

Observe this case (written in a poorly written tree form to show the (terminal) sequence (diagram)) where a user mashes the e a and r keys together (in any order) and we have a conflict whose state is resolved:

   We know this IS the only partial word match in our dictionary of english words right away...we know this by 
   looking at our dictionary and see that no other words exist with this pattern of chording + character entry, 
   so we change `ear` to `aer` and keep listening/looking for more anagrams if any exist...but we know 
   `ear + o` does not match any dictionary word
    |
    |
    v
    o - space
   /
aer   <-----chosen instead of `ear`... `earo` converts to `aero` as soon as the partial match to dictionary is found
ear
   \
    o - space 
    ^
    |
    |
    we know this is not a word right away as there is no match in our English dictionary of words...we have already 
    chosen the other word since there is no anagram of chords + sequence of chorded + character entries that 
    matches `ear + o` to any word in our dictionary.

To reiterate, as a user types we would get this:

1. aer -> ear
2. earo -> aero
3. aero + space -> aerospace

CONCLUSION
I know the chance this would get implemented is small, but I wanted to post it here as I have also posted it another place and hopefully it does get implemented somewhere. The biggest advantage for me is that I could chord words out of their roots or prefixes more easily...we don't have to do non-mnemonic chords for silly things like ear in order to avoid other chords are if we are typing them as a part of a larger word (e.g., earwax). I hope this sparks an interest in someone or at least entertains them 😂. Thank you for offering this great project!

[psoukie]

Thank you very much for the suggestion and detailed explanation. This approach is indeed quite different (and at first read, I thought incompatible) but it could be done, and there are significant parts of this that would benefit even the very different approach that ZipChord has.

ZioChord currently has a simple correspondence of one chord expands to one expression. (And it is possible to string the chords together to form longer words.) A big step towards your approach is an ability to have a correspondence of a sequence of chords to an expanded text, and (to get even closer) a sequence of a mix of chords and regularly typed characters to an expanded text.

The correspondences could be defined manually in a chord dictionary as "sequence to expanded" or theoretically (to get to probably a full implementation of your idea), those correspondences could be inferred from a dictionary of all words in a given language.

I would like to implement at least the first part of this. Before I say more on that, here are two complications (and one consideration) why ZipChord uses a different approach -- not to say this is "right" or that you are not aware of these.

1. On a standard keyboard, chords composed of (all) the actual keys that make up a word are impractical to execute (because of combination of different rows etc.)
2. A huge number of words would have the same basic chord ("part" and "trap" or "aloof" and "loaf")
3. The main motivation for chorded entry (at least for me) is to gain efficiency and ease of typing.

So chorded systems use tricks to reduce the amount of keys pressed simultaneously while encoding enough information (like having the same "sounds" represented on left and right part of the keyboard). But that comes with a steep learning curve.

So the story behind ZipChord was to leverage Zipf's law and get to being able to enter half of our typing with only 50-80 simple chords.

I understand your suggestion could address things like "aloof" by breaking it to "A" and "LOF" chord and while the latter could also be "fool", there's no "afool" in English.

But for most of the typing, like "part" and "trap" it's either between typing them manually or memorizing custom chords (whether those would be short like P+T for part and T+R+P for trap, or long like P+A+R+T and T+R+E+P. And if we want to have chords for everything, then again PART is also "tarp" etc.)

So that was a long detour but wanted to bring up that I am not sure if implementing the whole thing makes sense for ZipChord because most frequent words are short, and they conflict a lot.

But that's also why I like your idea a lot, because while ZipChord allows you to do:

pt -> part
 g -> ing

And type P+T then Y and Space+G to get "partying",

It does not let you do:

tr -> their
tr & fr -> therefore
tr & e -> there

These are not necessarily how I would define actual chords but they illustrate your point. It would change "their" to "therefore" if the TR chord is followed by FR. (And ideally allow combinations with single letters too as the third line illustrates.)

This is doable and maybe would even be interesting for other people. As I wrote, to get from this to your full request is not trivial, but it technically would be about inferring the corresponding combinations from a dictionary. But then there could appear more conflicts on this next level. But still, it is technically possible, and if you wanted ZipChord to use for that, this is how I think it could get there.

[Danc2050]

REPLY
I was not expecting such a quick and detailed reply, but I'm glad part of it could be useful to ZipChord!

I am new to this project, so I appreciate hearing the ins and outs and also the chording theory involved. I value and agree with all you said (1-3). If I were to map my request to 1-3, I'd say that this could help 1 by typing in root words or prefixes, etc. and 3 could be furthered along in the process. Unfortunately no hope for 2 in this suggestion...

And type P+T then Y and Space+G to get "partying",

I did NOT know this! This makes me want to use ZipChord even more...

I am not sure if implementing the whole thing makes sense for ZipChord because most frequent words are short, and they conflict a lot.

Being able to combine chords that modify the existing chord, like in your example, would still be a great improvement and like you said, would be a big step towards my approach. Your code is super clean and readable, so if I wanted to badly, I would consider extending it for my purposes also.

MODIFICATION OF ORIGINAL IDEA
One possible modification of ZipChorder (or some program) and my idea, would be to make explicit what chord sequences mapped to what output, instead of inferring it from a separate dictionary. So taking aerospace as the example again, an entry in the chording library may look like this:

aer + o + space     aerospace
 ...

This would prevent collisions by recognizing that aer (anagram of ear and are) is a part of a word, rather than a single chord, so we could have conflicting anagram chords, but the output of which would only be triggered on typing the full sequence of chords + character entries.

The disadvantage is obvious -- one would have to have multiple statements in the chording dictionary to form multiple words. For example, taking aer, one would have to have a line for aeroplane (aer + o + plane; or plane likely split up into its own chord + character entry).

OFF TOPIC PARTIAL RESOLUTION TO POINT 2

2. A huge number of words would have the same basic chord ("part" and "trap" or "aloof" and "loaf")

A little off-topic...and I am too inept at grammar to fully know if this is a good idea, but I wonder if collisions could further be reduced by separating chords out based on the grammatical context. In your examples (e.g., part and trap), there is no way around it (unless somehow sensing the context of sentences or surrounding words, which seems unlikely or difficult), but for a (silly) statement like "You are an ear", we have anagrams are and ear but are is a verb while ear is a noun. Anyways, not sure if this generalizes, but if I am chording + typing "you are an..." and then I chord aer, I would expect it to pop out ear instead of anagram are based on grammar context as we can expect (I think?) a noun to come next.

FINAL THANKS
Anyways, thanks for even reading and responding to these. I know it takes a lot of time to just read, think, and respond, not even counting the implementation time...

[psoukie]

Thank you for your kind words, and sharing these ideas. Quick comments:

And type P+T then Y and Space+G to get "partying",

I did NOT know this! This makes me want to use ZipChord even more...

ZipChord supports indicating the expanded text has affixes (prefix, suffix or both using the ~ character, as described in the readme), but if you want to primarily combine smaller chunks of text into words, it's probably easier to turn off adding smart spaces in front and after chords (on the Output tab).

Being able to combine chords that modify the existing chord, like in your example, would still be a great improvement and like you said, would be a big step towards my approach. Your code is super clean and readable, so if I wanted to badly, I would consider extending it for my purposes also.

MODIFICATION OF ORIGINAL IDEA One possible modification of ZipChorder (or some program) and my idea, would be to make explicit what chord sequences mapped to what output, instead of inferring it from a separate dictionary. So taking aerospace as the example again, an entry in the chording library may look like this: aer + o + space aerospace

This feature is something that -- if all of my code was super clean -- would take maybe 30 minutes to get running. It started as a mess because I never worked with a scripting language before and because getting to an implementation that worked more than two letter keys pressed took some trial and error. It will take a bit more to do this, but it's absolutely feasible.

I like the idea a lot because it gives everyone more possibilities and could be used in creative ways that go in different directions. For example (using spaces to indicate when keypresses are lifted, and tab to separate to expanded text):

dy	day
dy 1    Monday
dy 2    Tuesday
... 
mn 1 0	October
mn 1 1	November

Some of it can be done now, (D+1 to Monday), but it's less flexible (no combinations, and no retroactive changes) and cumbersome (finding alternative for 11.) Another use could be to emulate stenotyping software while still allowing standard typing. Some time ago, I wrote in a reply that with a suitabale dictionary, ZipChord could replicate stenotyping. Actually, for complicated words, stenotyping requires two separate words that get interpreted together. Just like in your idea. So I was wrong about ZipChord theoretically being able to be a replacement, but this feature would actually make it possible. (Even though this was not the original goal of why I made this tool.)

January is busy for me, but unless there's something I am missing, I have an idea implement this quickly. I created an issue for this under #103.

... I wonder if collisions could further be reduced by separating chords out based on the grammatical context.

Yes, they could, but this would be far more difficult. (And it's also language-dependent.) I'll keep thinking. I'd almost certainly need to rely on a third party solution for this.

[Danc2050]

dy day
dy 1 Monday
...
mn 1 1 November

This looks like an excellent idea...like you said, it can be combined in many different interesting ways.

Yes, they could, but this would be far more difficult. (And it's also language-dependent.) I'll keep thinking. I'd almost certainly need to rely on a third party solution for this.

Thank you for the feedback (as you are the language expert).

I have recently put up a chording device of mine for sale, so I will try to help this project as much as possible as I think it is the only chording software solution I have seen (except one on mac that was far less developed) and will soon be my primary option. Looking forward to using it in its present and future state! 😀

[jsampson45]

If using a scriptable editor such as Vim or Emacs, a chord might call a script, e.g., to translate a sequence of previous chord outputs into a different output. This would go a long way towards steno emulation if that is a goal.

[psoukie]

Thank you. That's basically the approach I am planning to take. I'm going to write the mechanism here over coffee to help me sort out my thoughts.

The script will be adding chords and single key presses into an input sequence array until:

• a space or punctuation is typed (other than as part of a chord)
• an existing "interrupt" happens (like clicking or moving the cursor)

and at these points it will be emptied. (For privacy and efficiency.)

The script will then try to find the longest exact match of the input sequence in the dictionary. (So a loop with "candidate" shortcuts where the first candidate is the whole sequence from first to last entry, the second is second to last, etc. until a match is found.) If a candidate matches, we replace the corresponding output sequence with the expanded text.

So it also needs this corresponding output sequence variable where we store a "digital twin" of what we believe the output of the sequence has been. This needs to be updated anytime ZipChord expands or modified the output. (This is needed so we know how many characters we need to delete and type over based on any replacements that already happened.)

Currently, ZipChord is not storing anything even in memory other than immediate key/chord, and doesn't store any assumed output. Instead, it tracks last input characteristic (space, punctuation, automated output...) and output length discrepancies (caused by additions and deletions around by its smart spaces feature) with binary flags only.

The new solution still won't store in memory more than the most recent sequence between "spaces" or punctuation.

Even the current version would have been easier to implement if I started with the pair of variables for input and output sequences, and as I wrote, in that case, I guess it would be a 30 minute job. Reworking the flags logic to the two paired variables will b a bit more work. But I feel it'll be a cleaner solution. (And less bug-prone.)

I have a work day today for my day job and then I'm teaching a class tonight, but I might be able to get this done during the evenings later this week.

The goal wasn't to replace steno (that would be a side effect), but the feature will make this tool more flexible, which I like a lot.

[psoukie]

A quick update on this feature request:

This week, I spent time outside of my day job on fixing bugs in v.2.0 RC1 and updating the documentation.

Next, there are two things I need to do before implementing this: add testing automation and refactor some of the code to a more flexible design.

As much as I’m tempted to bolt this feature on without these steps, I know they will save time (and pain) in development and testing.

Thanks for your patience on this!

[Danc2050]

Testing automation is a great idea...I do not believe that another project I bought into even had automated testing (beta testers for sure) and you are one man working for free to improve typing for us all... I am pretty booked this weekend, but I would like to get more into this program next week and hopefully will have more bandwidth to try something I've been wanting to do in the above and submit something for your review + consideration.

[jsampson45]

Wishing you all the best in this!

[Nooby-001]

Hi! I'm all for advancement but for me Zipchord is almost perfect the way it is, I don't want it to type all my words, just the most used ones (chords) and the longest/most annoying ones (autocomplete) All that with almost no learning curve and minimal setup. I also don't want to learn rules and/or a new typing system, I have enough aggravation learning Colemak, If I ever want or need to type really fast there's Plover, awesome software but you need at least six months to learn it and a very expensive keyboard.

Would I stop using Zipchord if it got too complicated? No, I think the app can get as advanced as possible while still being easy to use for non-techies like me. Obsidian does that, they have plug-ins that can cook a turkey (Dataview 🤨)for the chosen ones, we mere mortals just type plain notes, everybody's happy.

Just my noob opinion, keep up the good work!

[psoukie]

I hear you and agree with you about the dangers of feature creep.

I made ZipChord to fill a specific need for myself, which is what you describe -- a way to leverage Zipf's law, and bypass learning complex chorded systems. And that required a Plover-like tool that (unlike Plover) lets you mix chords and typing. And as a result, you learn a few dozen chords which can be much simpler than how you'd type those same words on stenotyping keyboard.

My goal is to make ZipChord easier and more intuitive, not more convoluted, over time. To illustrate how the feature discussed here could help simplify things:

Let's take the following, real entries in a dictionary to support most frequent words and suffixes:

kn	know
tk	take
;g	~ing
;lg	~{Backspace}ing

First, the good: I can write "illustrating" by typing illustrat and ;+G, or "knowing" with K+N and ;+G.

But for "taking" (or "having", "liking" etc., which are all extremely frequent verbs), I need that separate suffix (such as the ;+L+G in the example above) that deletes the last "-e" in those verbs. So this is already a bit convoluted, even though it's useful in typing all the time. (Actually, on Dvorak, I use .n and ,.n for the ~ing and the Backspace ~ing.)

If I add this feature, the dictionary could instead do this:

kn	know
tk	take
tk ;g	taking
;g	~ing

I would argue, this is actually a little less complex to explain, and much easier to use:

• "concluding" -- type "conclud" and ;+G
• "knowing" -- chord K+N and ;+G
• "taking" -- chord T+K and ;+G

It's elegant and consistent, and ZipChord cannot do this now.

The more flexible syntax would be just an option. It doesn't change how any existing dictionaries work, and does not require people to start using it.

[jsampson45]

Another example might be to alter the output depending on whether a space has been already typed or not. So unwanted double spaces would be avoided. Also, the Plover dictionaries have words composed of more than one stroke (chord). The strokes may represent a word each, but when consecutive together represent one word only.

[psoukie]

The initial working implementation is now available in version 2.2 Alpha: #155