Thanks, and I'll check out the alternative char stuff.
cm
On 08/18/14 12:19, Juergen Sauermann wrote:
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
