[Cuis-dev] [IMPROV] Unicode Input in Editor

H. Hirzel hannes.hirzel at gmail.com
Tue Oct 24 10:03:16 PDT 2023

Hi Gerald

Thank you for your answer.

On Thu, Oct 19, 2023 at 9:05 AM Gerald Klix <cuis.01 at klix.ch> wrote:

> Hi Hannes,
> I am glad that this feature works after some updates.
> Just to avoid any confusion:
> By 'IPA' you "International Phonetic Alphabet"?

It consists of 107 letters, 52 diacritics, and four prosodic marks.
All languages of the world for example use as vowels a subset of the vowel
inventory given here

And this is a facility to compose an expression by clicking on the symbols

> What you describe is some "optimized" keyboard handling,
> which reminds me a bit of a virtual smartphone or tablet
> keyboard. I presume a separate (extension-)package for
> this feature is best. Personally I dislike this compose key stuff.
> I strongly prefer either completely stateless UIs like Cuis'
> or statefull interfaces done right, like vi or vim.
> Anything in-between is just confusing.
> In other words:
> I don't care whether the sun rises in the east or the west,
> but it should be the same all over the globe :)
> Generally yes. However the backslash key is actually used as a 'compose
key' in your solution. And why not have one or two more 'compose' keys in
case of need? But as you write these things should go into one or more
extension packages for people who want this  to choose from.

> There is also a non-integrated change-set
> for code completion of \<latex symbol> input.
> (https://lists.cuis.st/mailman/archives/cuis-dev/2023-July/007876.html)

>>* I also thought about something like '\+UNICODE_NAME' where
*>>* taken from UnicodeData.txt: '\, so one write
*>>* "\+LATIN_CAPITAL_LETTER_A_WITH_TILDE" and it will be replaced with "Ã".
*>>* For such a form of input, completion would make sense;
*>>* actually it is unusable without completion.
*>>* Of course, this should not be in the standard image,
*>>* because it will consume a lot of memory.*

> I integrated this change into Haver and discovered that I use it
> maybe once or two times a month. My current impression
> is, that this sort of code completion is of little use, albeit
> I promised to fix its issues and re-post it.
> I would like to see this as a separate package! I think it is useful if
you want access to a rarely used Unicode symbol such as the IPA symbol for
'advanced tongue root'  even if this is only a few times in a month.  Why
do you think that code completion is of little use?

> Maybe it makes sense, to add a complete solution,
> including Unicode input with symbolic names and some
> sort of character table in, the aforementioned
> and yet to be written extension package.
Yes, I think this makes sense to make full use of Unicode. In fact a
search/autocompletion facility with the standard character names from the
Unicode table gives people access to this huge inventory of characters. A
solution should rely on this standard. As you wrote it should be in a
separate package. Memory is not so much a problem if people want to work
with an app which makes intensive use of Non-ASCII characters.

Best regards

> On 10/16/23 9:02 PM, H. Hirzel wrote:
> > Hi Gerald
> >
> > Thank you for checking the Unicode input in Cuis. In the meantime I also
> > installed the latest version of Cuis. So
> >
> > \+161<space>
> >
> > works fine for Unicode input.
> >
> > You asked for my IPA requirements. I have started preparing a list and
> will
> > post it when ready. It will also include characters from the Latin
> Extended
> > area for orthography purposes for many languages.

If we have a full solution for the IPA then what remains is an easy way of
keyboarding quickly non-ASCII letters on a keyboard only supporting ASCII
or not fitting  the language you want to type, e.g. French, German or a
language from Eastern Europe on an UK/US keyboard.

I see Szabolcs Komáromi working on an interesting solution.

> >
> > The <backslash> key acts as a compose character in this case[1].
> > We could also use other compose keys in addition.
> > For example after a semicolon in nearly all cases there will be a space.
> So
> > <semicolon><ASCII character> gives 25 more options. A comma is also a
> > candidate.  <comma><c> could be used for c cedilla. Even the letter q may
> > serve this purpose as with only very few exceptions there will always be
> a
> > 'u' following it.
> >
> > I discovered
> >     UnicodeCodePoint namedCharactersMap
> >
> > I did
> > UnicodeCodePoint namedCharactersMap at: #openo put: $ɔ
> > UnicodeCodePoint namedCharactersMap at: #o put: $ɔ
> >
> > this now allows me to have a new combinartion
> > \openo<space>      The space is still necessary and it needs to followed
> by
> > a backspace.
> > \o
> >
> > So this is easily extendable.
> >
> > You gave the link
> >
> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/commit/2c52852e716348f6350a461b0081ebe59971674d
> > which contains method
> > Editor>> normalCharacter: aKeyboardEvent
> >
> > I pasted the code into DrGro 23.06 and it made it work! So it seems that
> > all the input logic is contained in this method and the data is in the
> > dictionary UnicodeCodePoint namedCharactersMap. Is this so?
> >
> > I am yet to understand the full logic of this #normalCharacter: method.
> The
> > method also seem to deal with diacritical marks [2] but I did not manage
> to
> > add diacritical marks on top of vowels.
> >
> > Kind regards
> > Hannes
> >
> >
> >
> > [1] https://en.wikipedia.org/wiki/Compose_key
> > [2] Of main interest are acute, gravis, diaresis (trema) e.g. for Umlaut
> in
> > German and also for writing in French, and nasalization. This is on a UK
> or
> > US keyboard. https://en.wikipedia.org/wiki/Acute_accent gives a list of
> > some languages using it.
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20231024/448d4222/attachment-0001.htm>

More information about the Cuis-dev mailing list