Why Apple hates Home/End/Page Up/Page Down?

The behavior of keys when you are in a Terminal window is governed by what is running in that window (i.e. bash, vi, emacs, etc.), by the traditional tty driver and terminal emulation layers ("man terminfo" and "man stty" are starting points for that rathole), and by the settings of Terminal, including "Profiles" that define many of the tty parameters and keyboard->character mappings. Having spent many years as a sysadmin of diverse Unix-ish machines, I assure you that they do NOT all behave identically. Even across commonly used Bourne-like shells (e.g. bash, ksh, and BSD sh) the behavior of "vi" & "emacs" key bindings is not uniform. As the existence of shell options named after text editors demonstrates, the behaviors of various keys in text editors isn't even intended to be consistent. However, if you dive into the Terminal settings and make them match the default expectations of whatever non-Mac platform you are used to AND modify your shell initialization to not mangle that, you can get very good consistency between how the same programs behave between MacOS and other platforms. For example, I have a single Terminal Profile and common ~/.profile file that I use across 3 versions of MacOS, 3 versions of FreeBSD, 2 versions of Solaris, and multiple versions of 3 Linux distros that provides me almost perfect keyboard consistency across them all. It may not be encouraging to note that I've been tweaking that .profile for over a decade, not because of MacOS so much but rather because I keep running into new edge cases in narrow classes of (mostly Linux) systems.

The core problem that started this thread is that laptop keyboards are short on keys, and it isn't particularly obvious on Mac laptops how Apple makes up for that basic common problem. The critical unmentioned clue is the "fn" key, which swaps the functions of the Function keys between "standard" (i.e. app-visible) and Mac-specific system controls. Its lesser-known effects are to switch the arrow keys to Home/PageUp/PageDown/End keys, swap the Return key from CR to LF, and swap the delete key from DEL (0x7f) to the VT100 backspace sequence (ESC[3~).

As for GUI text editors, it is wrong to blame Apple for inconsistency there. They have long published guidelines, provided the example of TextEdit (and SimpleText before it) and provided usable basic text editing widgetry in every Mac API going back to 1984. Also dating back that far is the mostly delusional insistence of developers that their UI preferences and/or alternative implementations of editable text views are better than Apple's.

billcole:

Thanks for an excellent response.

Would you be willing to:

1) Share a version of your .profile here, and/or

2) Cross-post it to serverfault.com

I think that might spark a very constructive discussion.

Hal B.

Oregon, USA

billcole wrote:

Also dating back that far is the mostly delusional insistence of developers that their UI preferences and/or alternative implementations of editable text views are better than Apple's.

This was often the result of porting existing software to a new platform. A company writes software for DOS and has a successful product for a few years. Everyone gets used to the menus and keys they use in the DOS version. Then they port the editor to other platforms. Most platforms don't have Apple's Human Interface Guidelines book which says how menus and keys are meant to work, so on most platforms they just copy how the menus and keys work from the original version.

Unless they have a Mac fanatic on staff there's nobody to tell them that Apple has already decided these things and if they don't conform to the way Apple wants it done they're going to get complaints from Apple users. Or sometimes the Managing Director of the company tries the Apple port and finds he can't use it and just tells his employees to make it work like all the others.

Doesn't happen so much these days. First, even the Windows Business Unit makes sure that Office on the Mac works the way a Mac user would expect it to [1]. Second, Windows has grown to be so big and so complicated that it has is own HIG documentation Windows User Experience Interaction Guidelines so even Windows programmers are familiar with the idea that it's the OS-designers who set these things. Gnome has one too:

GNOME Human Interface Guidelines.

Simon.

[1] I read somewhere that in the Office test labs user testing for the Mac version had so many complaints saying 'this doesn't work like a Mac app should' that they couldn't get any other bugs in the Mac version noticed.

Well, it's been nearly a year since my last comment on this thread and here I am again, searching for a mindless solution. I suppose my confoundment here stems entirely from opening a shell/terminal/console on Linux (or a dos shell / putty on Windows) and in every single case having these keys function as expected. When I boot my Mac in to Windows or Linux, the keys work the way I expect.. When I use my full-size Apple keyboard, I get the same unexpected behaviour. I guess from the above comments there is definitely a method to the madness. Though that method seems to appeal to purists and feels to me almost like a point of historical fact and has little to do with conventions that have evolved elsewhere. Suffice to say, I often use VMs on my Macs anyways and so this doesn't really bother me like it used to, but it would be nice if a change came around.

I'll take a stab at this as I'm new to Mac, and a veteran of the *nix, VMS (not VMs) and Windows world.

First a little background:

The DOS command prompt did not support HOME, END, UP, DOWN, LEFT or RIGHT for years. It only supported F3 to recall last line and BACKSPACE to erase the character to the left of the cursor. Then around Windows 95 or so, it added the ability to use LEFT and RIGHT and INS to move left and insert characters. And finally, with the NT-based command prompt (essentially from DEC VMS, but that's another story), they added a full command-line history and editing modes. There had been replacement command shells, and overlays that provided these functions for years, but out of the box, nope.

*nix, Linux and Unixen included, have been worse off. stty is the program in *nix that controls the terminal interface for most of the shells (sh, csh, ksh, bash) and it has fairly limited support of special keys (special keys didn't have standard key codes until the 90s). So, if you sat at an IBM Terminal connected to an IBM Server running IBM AIX, and ran an AIX ksh in an aixterm, then for some applications your keys would work correctly and the command line worked mostly as expected within the limits of ksh. But, it was super inconsistent, and as soon as you ssh(neé rsh)ed in from another host, all bets were off.

When linux started it, it was much in the same boat. And even upgrading your keyboard caused no end of grief on how the command line behaved (and in some cases even the graphical interface had issues with keys).

But, now in the glorious future, all these problems have gone away. Kind of.

Terminal is a barely enhanced version of the xterm applicaiton OS X inherited from BSD(?). There are advantages in OS X for making this a very lean change, it's fast, it performs predictably, it acts like the X Terminal that command line apps expect, and it behaves almost exactly how *nix nerds expect it to.

But, it is not the rich command line application that CMD.EXE is, in fact, it's not a comand line application at all, it's a terminal emulator, which launches the default shell (usually bash, or Bourne Again Shell).

Now, PuTTY is a terminal emulator, more specifically it's a ANSI terminal emulator that does PC keyboard conversions on the fly. If it mates up with your target OS and can set the key mappings correctly, you're in like Flynt, but when it screws up, it takes some doing to fix.

So, back to Mac OS X Terminal. It runs a fairly simple wrapper around xterm, in fact, if you ask bash what terminal it thinks it's running (echo ${TERM} ), it reports 'xterm-256color' (an xterm that supports ansi 256 color text mode).

As an old unix nerd myself, when I login and I see the fixt width font and the obvious bash prompts, I expect my session to default to Emacs editing mode (which it does).

http://www.math.utah.edu/docs/info/features_7.html

And subsequently, I can Ctrl-A, Ctrl-E, Ctrl-D, Ctrl-P and Ctrl-N to my hearts content. Heck even DELETE, LEFT and RIGHT work as expected. But, what gives with HOME, END, PAGE UP and PAGE DOWN?

Well, in the olden days most terminals didn't have those keys, and keyboard implement them a little differently. They have escape codes in them (like ESC]0x2C). So, a lot of the legacy unix shells and utilties cannot interpret them.

How does Linux do it? Well, Gnome Terminal has a lot of enhancements, and the shell understands Gnome Terminal, and Gnome Terminal has keyboard mappings for all the special keys.

But, and this is key, Linux is built for command line hackers, so the self-same command line hackers have invested an inordinate amount of time fixing these things. And, Linux ships with a clone of xterm, for when Gnome Terminal screws something up.

Mac OS X does not ship with a fancy Gnome Terminal (but you can install it if you want), it comes with the basic debugging terminal, that they don't expect their core users to use. I don't think early Mac OS even shipped with a terminal application, until they switched to the BSD core for Mac OS X.

But, it provides all the hooks for one to be developed a quick google shows:

http://lifehacker.com/5857046/the-best-terminal-emulator-for-mac-os-x

http://iterm.sourceforge.net/

http://software.jessies.org/terminator/

And the App Store has over 30 terminal emulators.

I doubt that the company credited with the popularization of the GUI, will do much more than an xterm. I'd recommend experimenting with some of these alternatives (I'd start with the free ones, and google for reviews).

One terminal emulator that I missed, but is a must try: SecureCRT

http://www.vandyke.com/products/securecrt/

I've used it in Windows to attach to AIX, HP-UX, Linux and Solaris hosts. It does a great job and has no shortage of features.