pinchord-14 Chords Format

Pinchord · pinchord.git · Tickets · Changelog

A Pinchord Ticket (Closed):

Ticket · History

Closed, Javelin support has been dropped

pinchord.git branch: chords-format

Pinchord has always meant to be an extensible system. I made a set of chords that I like - they happen to be particularly pinky-heavy, favor ease of memorization and consistency over speed and ergonomics, and are purely for the English language.

These things are not for everyone, and nothing about the nature of Pinchord or its implementation bakes these ideas in, they're just my preferences that I encoded into the chords themselves.

So naturally, a few people who have learned Pinchord have designed their own derivations. These are great, and they should be well supported, but they are not.

Pinchord sits on the two major hobbyist steno engines, Plover and Javelin, and is implemented separately on them both. Plover is an application written in Python, and you can use Python dictionaries to create basically whatever behavior you want. Javelin is an embedded firmware written in C++, and does not have a trivial method of extension, or an equivalent to Python dictionaries¹. Javelin has a built-in orthospelling dictionary format in yaml, which Pinchord (ab)uses to get its intended behavior.

When I update Pinchord's chords, I edit the yaml dictionary and the Python dictionary separately, and ship them both. When I update Pinchord's behavior, I have to figure out how to implement that behavior separately on Plover and Javelin, often delaying things that are trivial to fix on Plover because they are very much not on Javelin :p

It's kind of too much work to impose on someone modifying Pinchord, who, invariably, almost certainly uses either Plover or Javelin, leading to the obvious and easiest choice of implementing their derivation as either a Python dictionary or a yaml orthospelling dictionary.

As a user of this derivation, of course, you may be on Plover or Javelin as well, but that derivation might not have an implementation for your engine. I would love to recommend different derivations of Pinchord to people with different needs, but right now Pinchord itself (with the default chords) is the most usable because I put in all this work that I'm sure nobody else wants to :p

This fragmentation of implementation is a symptom of there being no common ground between these engines when it comes to a system like Pinchord², so one should be made.

I'm sure this lack of expression is limiting the extremely vast set of implementations that could and should exist for this type of system.

Alternate keyboard layout users and creators, who are one half of Pinchord's target audience, are used to fitting layouts to their needs and being able to update and share these layouts trivially, which Pinchord is severely lacking.

A standard format for representing, modifying, and sharing Pinchord derivations would bridge the gap between the two engines, and give an easy and obvious way for users to fit the layout to their needs, and to share that with other users.

While there's nothing wrong with Pinchord's chords, they're just not for everyone - nor are any other set of chords. These things are personal, and there are just way too many factors to optimize for and trade-offs to make.

Implementation

Plover and Javelin use entirely separate formats for representing orthospelling, so it seems that a single format either has to:

1. Be one of the existing formats, and/or
2. Compile/translate to one or both of the existing formats

Either fitting Plover's Python dictionary to generate Javelin files when run, or implementing Javelin's yaml orthospelling format in Plover, seem to be the two obvious options to me, but there's more thinking to do here.

Att: attachment: chords format implementation

Footnotes even though I hate footnotes: