Re: [Bug-apl] Possible bugs in ]keyb output

[Juergen Sauermann]

Hi,

regarding ⋸ vs. ⍷ they are both in ⎕AV. If I remember correctly  I was asked earlier to change from one to the
other and did so. Both are listed in Aved.def (called EPSILON_UBAR and EPSILON_UNDERBAR). One of them
(probably EPSILON_UNDERBAR) may disappear if the space is needed for new functions (I hope not, though).

GNU APL accepts both and they refer to the same function. So you can put the one you prefer into your keyboard
mapping. Defined function keep the one used. Debug output of APL token uses EPSILON_UBAR.

I have changed how ]KEYB works as of SVN 437. You can now specify a keyboard layout text file in the preferences file(s).
If you do that then that file is printed instead of the default keyboard layout. The old method of providing a method number
has been removed. The default layout shown by ]KEYB is also installed in .../etc/gnu-apl.d/keyboard1.txt and can be used
as a starting point for your own file.

Chris, you may want to have a look at function Avec::map_alternative_char(). It has a list of additional Unicode chars that
are used by other APL interpreters and also understood by GNU APL (and mapped to chars in ⎕AV).

/// Jürgen


On 08/16/2014 09:26 PM, Chris Moller wrote:

For a few days, David Lamkins and I have been kicking around a problem in the ]keyb output.  Turns out the least tractable of these seems to be the result of two different utf8 sequences used for the epsilon-underbar character:

]keyb    uses utf8 e2 8b b8, unicode 22f8, "ELEMENT OF WITH UNDERBAR"

]keyb 1 uses utf8 e2 8d b7, unicode 2377, "APL FUNCTIONAL SYMBOL EPSILON UNDERBAR"

The first of these, U+22f8, doesn't exist in either the FreeMono or SimPL fonts; I'm guessing that GTK's text engine, pango, is just grabbing the closest glyph it can find from some other font, which turns out to be of a different width.  U+22f8 isn't in Avec.def.

U+2377 exists in both fonts and corresponds to EPSILON_UNDERBAR in Avec.def.

I'm more or less guessing that the data for ]keyb comes from either keyboard.dyalog.txt or keyboard1.dyalog.txt, both of which contain the broken U+22f8 character while ]keyb 1 comes from either keyboard.txt or keyboard1.txt, both of which contain the working U+2377.  No idea, of course, if these differences are deliberate.

Anyway, the latest push of aplwrap is stable with respect everything except dealing with these differences in ]keyb output.

Chris Moller