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 abcdefg 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? 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 > <[email protected]> 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 <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Peter Teeson <peter.teeson@...> <mailto:peter.teeson@...> 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 >> >
