[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-apl] MacAplAlt.keylayout

From: Peter Teeson
Subject: Re: [Bug-apl] MacAplAlt.keylayout
Date: Fri, 18 Sep 2015 09:49:45 -0400

Hi Jürgen:
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
a b c d e f g

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?


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

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:
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 &#x0009; using the Ukelele application- which I use to make changes to the MacAplAlt.keylayout.
For example the Return key has a Unicode value of &#x000D;

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.

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?


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: 

The last two look like Quad with the font in my browser right now,
but they're not.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]