bug#73909: [PATCH 2/2] quail/greek.el: Add greek-polytonic.

[Visuwesh]

[திங்கள் அக்டோபர் 21, 2024] Robert Pluim wrote:

>>>>>> On Mon, 21 Oct 2024 20:01:20 +0530, Visuwesh <visuweshm@gmail.com> said:
>     Visuwesh> You have to set quail-keyboard-layout to a suitable
>     Visuwesh> value using the
>     Visuwesh> command quail-set-keyboard-layout.  But we don't have
>     Visuwesh> any entry for
>     Visuwesh> AZERTY in quail-keyboard-layout-alist so you'd need to
>     Visuwesh> add a suitable
>     Visuwesh> one yourself.
>
> Ah, I used the OS-level tools to change the keyboard layout, which is
> not the same thing.

It is a bit convoluted.  When you change the keyboard layout at the
OS-level, Quail does not have a clue that you're using a non-"standard"
keyboard layout.  So you need an entry in quail-keyboard-layout-alist
that instructs Quail about your OS-level layout.  Without this entry,
Quail input methods like greek-polytonic, english-dvorak, etc. are no
longer functional since they rely on non-nil KBD-TRANSLATE [1].
I hope this clears up the confusion.

>     Visuwesh> When this is done, KBD-TRANSLATE=t with that entry should make a
>     Visuwesh> difference.
>
> Looking through that list, thereʼs only 1 type that I *might* have a
> physical example of, in storage somewhere for the last 20 years 😀

I understand.  It is too outdated.  We should add contemporary layouts
to it like AZERTY, Dvorak, etc.  It shouldn't be too hard.  It is about
time I sent a patch for this...

>     Visuwesh> It has been a long time since I last tested this so my
>     Visuwesh> memory is in
>     Visuwesh> shambles.  I can test it later on if you want.
>
> Sure. If it enables people to use greek-polytonic as an actual layout,
> we can retain the identity mappings. But I still think itʼs going to
> be a *really* obscure use case.

Please evaluate (this does not accurately model the AZERTY layout
properly since the number of keys in the qsd row is different from the
US standard keyboard layout which is what I have)

    (setf (alist-get "azerty" quail-keyboard-layout-alist nil nil #'equal)
          (concat
           ;; Above 1-0.  30 because 15 keys -> shifted and unshifted.
           (make-string 30 ?\s)
           "  &1é2\"3'4(5-6è7-8ç9à0)°=+₂   "
           "  aAzZeErRtTyYuUiIoOpP̂̈$€    "
           "  qQsSdDfFgGhHjJkKlLmMù%*μ\\|  "
           "  <>wWxXcCvVbBnN,?;.:/!§      "
           (make-string 30 ?\s)))

then do:

    1. M-x quail-set-keyboard-layout RET azerty RET
    2. Change OS-level keyboard layout to azerty
    3. Evaluate the relevant forms to add greek-polytonic Quail IM
       ensuring that KBD-TRANSLATE is non-nil
    4. C-u C-\ greek-polytonic RET
    5. Type "&" as per AZERTY layout, this will insert 1 as you would
       expect from a greek-polytonic keyboard

When you remove ("1" . ?1) from the translation rules and repeat step 5,
you would insert "&" instead.  I doubt inserting "&" is what the users
of greek-polytonic would want.

This is the same wrt english-dvorak too: if, as an AZERTY owner, I press
the physical key named "&" in my keyboard, I would want Emacs to insert
"1" when english-dvorak IM is active.



1. In this scenario, when you press "&" with
   quail-keyboard-layout="azerty", Quail converts this to "1" since
   that's the key that "&" corresponds to the "standard" layout.  This
   converted string is then passed to the Quail IM which, in our case,
   is greek-polytonic (T&C applies).