unimnim is an input method that uses mnemonics to input as much of Unicode as possible. It's inspired by m17n's RFC1345 input method and compose sequences.
In general, a mnemonic starts with a prefix for the script, then a mnemonic for a letter or symbol, then some optional combining mnemonics for accents. For example:
| Group/Script | Mnemonic | Result | |
|---|---|---|---|
| Prefix | |||
| Arabic | A | b | ب |
| Bopomofo | bo | b | ㄅ |
| Buginese | bu | ka | ᨀ |
| ki | ᨀᨗ | ||
| Buhid | bd | ka | ᝃ |
| ki | ᝃᝒ | ||
| Cherokee | ce | GA | Ꭶ |
| Cyrillic | C | k | к |
| k' | ќ | ||
| Devanagari | D | k | क् |
| ka | क | ||
| kim | किं | ||
| Ethiopic | E | ha | ሀ |
| Gothic | gt | a | 𐌰 |
| Greek | gr | a | α |
| a' | ά | ||
| Hangul | hg | ga | 가 |
| gag | 각 | ||
| Hanunoo | ho | k | ᜣ᜴ |
| ka | ᜣ | ||
| ki | ᜣᜲ | ||
| Hebrew | he | k | כ |
| k] | ך | ||
| k. | כּ | ||
| ke | כֶ | ||
| Japanese syllabaries | K | ka | か |
| KA | カ | ||
| Latin | L | o | o |
| o/ | ø | ||
| o/' | ǿ | ||
| oe | œ | ||
| Ogham | om | b | ᚁ |
| Osmanya | os | b | 𐒁 |
| Runic | ru | b | ᛒ |
| Sundanese | su | k | ᮊ᮪ |
| ka | ᮊ | ||
| ki | ᮊᮤ | ||
| kar | ᮊᮁ | ||
| kra | ᮊᮢ | ||
| Tagbanwa | tb | ka | ᝣ |
| ki | ᝣᝲ | ||
| Tifinagh | tf | r | ⵔ |
| t | ⵜ | ||
| r-t | ⵔ⵿ⵜ | ||
| Thaana | th | h | ހް |
| ha | ހަ | ||
| a | އަ | ||
| Vithkuqi | vi | a | 𐖗 |
| Yi | yi | it | ꀀ |
| qotR | ꒐ | ||
| math | ZM | 0s | ∅ |
| +n | ∑ | ||
| &l | ∧ | ||
| &s | ∩ | ||
| == | ≡ | ||
| ==! | ≢ | ||
| punctuation | Z | -h | ‐ |
| -m | — | ||
| 'q | ’ | ||
| 'p | ′ | ||
| ?! | ‽ | ||
| ?!I | ⸘ | ||
| arrows | ZA | - | ↔ |
| | | ↕ | ||
| currency symbols | Z$ | Rs | ₨ |
| music | Zm | n/4 | 𝅘𝅥 |
| n/4.2 | 𝅘𝅥𝅭𝅭 | ||
| n/4> | 𝅘𝅥𝅻 | ||
| nx| | 𝅃𝅥 | ||
| other symbols | Z | co | © |
| regional indicators | ZRI | UN | 🇺🇳 |
| tag sequences | ZTS | Fgbsct | 🏴 |
See the data directory and its README for more details.
The easiest way to try this out is probably by going to the GitHub Actions
workflows,
clicking on the most recent build, and downloading the python-3.13-output zip
file at the bottom of the page.
Extract unimnim.mim from the zip file above to ~/.m17n.d/, and install an
input method that supports the m17n library. I'd
recommend
ibus-typing-booster, and
I've used ibus-m17n in the past. I've never
used fcitx-m17n, but it looks like it
might work too. I don't have a Mac to test on, but it looks like there might be
a way to use it on macOS too.
Whichever you use, configure it to use the t-unimnim input method.
If you type normally, unimnim stays out of the way. To use it, type
Alt + \ followed by a mnemonic. To search mnemonics by
prefix, type Alt + \ twice and start typing a mnemonic.
If you want to use different key combinations, see the documentation of
minput_event_to_key
and add lines like these to ~/.m17n.d/config.mic:
((input-method t unimnim)
(command
(start nil (C-`))
(search-prefix-start nil (C-` C-`))
)
)
If you'd like support for a different engine, please file a feature request. If
you want to integrate unimnim's mnemonics into other software yourself,
map.json in the zip file above is a simple JSON object with all the mnemonics
and their results.
uni and mn are pronounced however you'd pronounce them in Unicode and
mnemonic. im is entirely up to you. Personally, I pronounce it the same as
uninym.
The code only generates output files for other input method engines to use, so software stability hopefully isn't an issue.
The data is α. There might still be significant changes to the mnemonics. At this point, internal consistency is valued over stability. When adding a new mnemonic, if it makes sense to first change other mnemonics so they can all use the same pattern, that change should generally be made.
Unfortunately yes. I tried to find data on the most common keyboard layouts and the keys shared by layouts used by the most people before starting this project, but I didn't find much.
If you want to use this input method with another layout, please file a bug.
For small changes like changing the currency
prefix from Z$ to Z followed by a
currency symbol on your keyboard, I think it would be easy enough to add support
for prefix overrides.
For medium changes like adding læ' as a mnemonic for ǽ in addition to the
current lae' mnemonic, I think it would make sense to automatically generate
parts of [maps.main]. The input method templates might need modification too.
E.g., it looks like m17n would need a different syntax for the
mnemonics.
For large changes like adding mnemonics in a script other than Latin, I'm happy to think about it more. Maybe it makes sense to have separate data directories?
For many use cases, switching between a few keyboard layouts is probably better than using mnemonics. For each language with a good keyboard layout, I think it's probably much faster for an experienced user of that layout to type directly than to use unimnim. However, unimnim has advantages in other use cases:
- There are a lot of mnemonics for characters that (as far as I know) aren't common on normal keyboard layouts, like different types of dashes, mathematical symbols, music symbols, other symbols (©, °, ℅, etc.), and bidirectional formatting characters.
- For a language I only type in once every few years, I find it a lot easier to use mnemonics than to remember a different keyboard layout and to keep track of which layout I'm currently using.
For typing a limited set of accented characters in one script, compose
sequences and/or
dead keys might be easier and/or
faster. When I've looked into it, the support for more obscure characters and
multiple scripts didn't look as good though. Also, compose sequences don't seem
to support overlapping
mnemonics,
which I think makes it harder to get visual feedback while typing a mnemonic.
For example, after typing lae, unimnim should show æ, then typing the
additional ' changes that to ǽ.
RFC 1345 defined a somewhat similar set of mnemonics in 1992, and there's an m17n input method using those mnemonics. That served me very well for multiple decades, and I think it is a pretty good set of mnemonics. unimnim is very much inspired by it.
However, it seems to have been intended for use in standards documents to define character sets, not for use in an input method to type those characters. That combined with its age leads to some drawbacks:
- No support for the many many characters that have been added to Unicode since 1992.
- Since it tries to encode every character in old character sets, it includes characters that are no longer recommended for use in new text. (Which is not the same as characters for old writing systems. Those can still be recommended for new transcripts of old writings or for discussing those writing systems.)
- It has some patterns that it mostly follows in the mnemonics, but there are many exceptions to remember.
- Its mnemonics are limited to a smaller character set than are available on many modern keyboards, making some of the mnemonics a bit more awkward.
Additionally, the m17n input method based on RFC 1345 uses & as a starter
character to introduce a mnemonic, which makes using it while writing code in C
or C++ somewhat annoying. (That could probably be made configurable though.)
If you only rarely need to type characters that aren't on your keyboard, some sort of character search is probably easier than remembering mnemonics. I personally use ibus-typing-booster's search and emoji picker and GNOME Character Map in addition to unimnim.
CLDR has
transliterations
that have some similarities to the mnemonics that unimnim uses for different
scripts. However, the transliterations seem much better suited to reading text
than to writing it. E.g., they give an example of transliterating Αλφαβητικός to
Alfavi̱tikós, which does not solve the problem of how to type i̱ and ó.
I don't have any experience with these, but Input Pad looks interesting, macOS seems to have a way to press and hold a key to get accents, and it might be possible to use an on-screen keyboard with a different layout than the physical keyboard.
This repo follows the reuse specification. See file headers for what license(s) each file is available under, and the LICENSES directory for the text of the licenses.
The intent is that all of this repo can be used under the terms of Apache-2.0. Additionally, data files and templates can be used under the terms of CC0-1.0, and some templates can also be used under the terms of whatever license(s) are common for the type of input method the template is for. If you find a file that doesn't match that intent, please file a bug.