Before diving into debugging GNUAPL I did the following which points at the Terminal application as the culprit:
1. Open any text editor (TextWrangler in my case).
2. Select the MacAplAlt keyboard as the input device.
3. Type this
Note that TAB works as expected.
4. Launch Terminal and using the MacAplAlt keyboard as the input device type the same thing.
Last login: Fri Sep 18 09:31:30 on ttys000
Gandalf:~ pteeson$ abcdefgh
-bash: abcdefgh: command not found
Gandalf:~ pteeson$ ab cdefgh
When pressing the TAB key the cursor does not move (except 1 space after the b). Instead I hear a beep.
So I claim terminal does not process TAB in the way we expect in text editing/word processing.
I’m not sure how to proceed further on this. Any suggestions?
respect…
Peter
P.S. It also supports the observation that Xcode does handle TAB in the debug window.
On Sep 18, 2015, at 6:12 AM, Juergen Sauermann <
address@hidden> wrote:
Hi Peter,
character input is done in several places, but always by functions
called getc() or fgetc():
Command.cc:
const int cc = fgetc(layout);
Command.cc: const int cc = fgetc(pipe);
Command.cc: const int cc = fgetc(in);
IO_Files.cc: const int cc =
fgetc(input->file);
LineInput.cc:const int b0 = fgetc(stdin);
LineInput.cc: const UTF8 subc =
fgetc(stdin);
LineInput.cc: const int bs = fgetc(stdin);
Quad_SVx.cc: for (int cc; (cc = getc(fp)) != EOF;)
CERR << (char)cc;
Svar_DB.cc: for (int cc; (cc = getc(fp)) != EOF;)
UCS_string.cc: const Unicode uni =
UTF8_string::getc(in);
UTF8_string.cc:UTF8_string::getc(istream & in)
I believe the one you are interested in are the ones in LineInput.cc.
After an entire input line was entered by the user, it is passed
pack to the caller of
get_line() (again, several places where this happens, and get_line()
is defined in several
classes).
Parsing of the terminal input is dependent on the mode (immediate
execution, ⎕-input, etc.)
and happens after get_line() has returned.
Keyboard mapping happens outside GNU APL (before the getc()
call returns).
/// Jürgen
On 09/17/2015 01:33 AM, Peter Teeson
wrote:
Hi Louis & Jürgen:
Jürgen:
I can try to de-bug in Xcode but I need to look at
where the Terminal input is parsed.
But I forget where that is in the source code.
Hmmm…. Now I’m more confused than usual.
I set TAB to 	 using the Ukelele
application- which I use to make changes to the
MacAplAlt.keylayout.
For example the Return key has a Unicode value of

In Xcode when I
Run the binary things work as expected.
Mind you I do launch it with —noColor —noCIN so as
not to get extraneous terminal formatting.
note that alt-TAB,
shift-TAB, and alt+shift+TAB present the glyphs that you
indicated.
Thats because I did not set them to have Unicode
values. However TAB itself works correctly!
But interestingly when I run apl from Terminal I get this:
Gandalf:~ pteeson$
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/apl;
exit;
which has the same glyphs
as in Xcode and your email.
But the TAB key seems to be nil
potent. The cursor just remains at the
indented position.
Louis:
Out of curiosity:
Which model Mac? Which version OS X?
I assume that you:
• set System Preferences / Keyboard / Input
Sources to Show Input menu in Menu Bar?
• that you added the MacAplAlt by pressing the
+ icon and scrolled to the bottom of the displayed
languages to Other?
• you have APL333 font installed?
• you have MacAplAlt selected as input?
respect…
Peter
On Sep 16, 2015, at 4:55 PM, Louis de
Forcrand <
address@hidden>
wrote:
Peter Teeson
<address@hidden>
writes:
Louis please confirm that the TAB key now works on
your Mac by placing this new layout in
~/Library/Keyboard Layouts.
Sorry to say, this one still types out:
TAB:
SHIFT+TAB:
ALT+TAB: 𐀆
SHIFT+ALT+TAB: 𐀅
The last two look like Quad with the font in my
browser right now,
but they're not.
⊣Louis