-
-
Save Melvar/1049589 to your computer and use it in GitHub Desktop.
To write an XCompose file, it is normally necessary to enumerate all the desired | |
sequences individually. However, there are many sets of related sequences with | |
common prefixes, as well as ones that differ only in a prefix, but have the same | |
result. Grouping such sets of sequences together, writing the prefix only once, | |
could ease both the initial writing and later changes (note that I do not assert | |
that it actually does). | |
This document is meant for suggestions on and discussion of both this concept | |
and possibilities of execution as a text-based notation that can be transformed | |
back into XCompose sequences. | |
A group would contain sequence-target pairs, where a sequence is a (possibly | |
empty) sequence of keystrokes and a target is a group or an output. As a group | |
could contain the same sequence multiple times or contain sequences that are | |
prefixes of other sequences in the same group, finding the output of a given | |
sequence could require following multiple paths at once. | |
Using the empty string as a sequence is equivalent to including the target in | |
the current group. Using the same sequence to target two groups is perfectly | |
sensible if the two groups have disjoint sequence sets. | |
Groups would probably usually be named, but anonymous inline groups could save | |
defining a group (and naming it) for just two or three related sequences used | |
only in one place. | |
The notation could be realized as a superset of existing XCompose notation, | |
which would allow simply using an existing XCompose file and converting it bit | |
by bit as desired. |
You’re right, it’s only certain classes of symbols that this helps with … one thing I thought of before was that it would easily be possible to convert from an XCompose file to a state-based notation little by little by translating the state-based things and catting them together. Now I think it would be a good idea to simply use a hybrid format, using the different approaches as appropriate. For example, your ♫s sequences are absolutely unrelated, the ♫& sequences (or whatever you made them into) thematically share almost nothing yet have a meaningful prefix (for changing which a relevant state might have been convenient), and the Greek letters were somewhere defined by ♫* , a thematic prefix. Let me just generalize this out …
Yeah; using this for some parts of the file, making it a tool and not a new way of doing everything, might be useful. Indeed, I have used prefixes more than once, the ♫♫ prefix for "longish things", unrelated (that's what I changed the & into), but also ♫* for Greek, ♫# for musical symbols (♯♭
Basically, you can sort of look like it as a prefix-tree. Something like:
And so on; I could write up better examples probably. Thing is, organizing it like that can be helpful for some things, but confusing for others. So for example, I have in my dotXcompose the following combinations that start with s:
But now they'd wind up as
i.e. they'd all have to be grouped together, because they share a prefix. It isn't a bad way to look at them (there's something to be said, on the contrary, for something that translates from an XCompose file into a format like this, so you can see the prefix tree. My duplicate-scanner program creates a data structure much like this), but it isn't necessarily enlightening: grouping the symbols with things that are like them and not things that just share a prefix is probably more useful.