[Suggestion] Support converting input to sitelen jelo as an alternate input method

[gregdan3]

For reference, sitelen jelo is a much more recent emoji-based writing system. You can read more about it here, but the short of it is that it improves significantly on the weird decisions of the previous sitelen Emoji, most importantly by letting any apt emoji be used in place of the recommended ones. For example, the default character for kala is 🐟, but it would be perfectly acceptable to use 🐙 instead.

It would be awesome to have a specific input method for this, and unless I'm totally mistaken about how IMEs work, it seems like it would be really easy to swap all the current targetable characters in the table for appropriate emoji characters.

[dec32]

it seems like it would be really easy to swap all the current targetable characters in the table for appropriate emoji characters

Yes and no. To compile a customized version of the input method, the only major thing you need to do is to edit the hard-coded mappings in src/engine/mod.rs. However, the current design of the matching engine only allows exact one mapping for one specific spelling, which makes it impossible to map one toki pona word (e.g. kala) to multiple emojis (e.g. 🐟 and 🐙).

To alternate the design of the matching engine, quite some refactoring needs do be done.

[gregdan3]

To alternate the design of the matching engine, quite some refactoring needs do be done.

Ahh, that makes sense, especially given the ability to continuously type and it match to multiple consecutive characters.

You may still need to perform that refactoring anyway, if the variation sequences we've been discussing in the Unicode proposal make their way to UCSUR- we're currently unsure if UCSUR supports this. Unicode themselves say no, but despite that, they seem to work in every software environment we've tested them in. Although, by their nature, nothing says you have to support variation sequences in the first place; they're fine to abandon.

[dec32]

Could you offer some more information about "variation sequence", some links maybe?

[gregdan3]

Yep!

Most of the valuable info is here.

The intent is that you use a variation selector after your target character, and if the current font and software environment support it, you will get a specific version of the target character rather than the non-varied default. This may be a specific realization or a font default, but does represent the same semantic object according to Unicode.

In sitelen pona, this would be relevant for cases such as the distinction between the two hearts version of olin versus the one heart and emitters version of olin.

These aren't in UCSUR yet, so it isn't a concern in the near feature. Additionally, the wording on the FAQ seems to imply that variation selectors should not be used in the private use area, since PUA is itself the fallback from using unencoded variation selectors outside PUA.

[dec32]

I see. To support variation sequences the same kind of refactoring indeed needs to performed.

By "as an alternate input method", do you mean an standalone IME that user can install on their machine, or a mode within Ajemi itself that user can switch to?

[gregdan3]

By "as an alternate input method", do you mean an standalone IME that user can install on their machine, or a mode within Ajemi itself that user can switch to?

I was imagining a mode within Ajemi that could be selected after installation, but anything you feel is appropriate goes.

[dec32]

Added. You can now use Ctrl+Shift+N to switch to (and back from) Emoji mode.