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
|