Cannot enter # on British Keyboard

[verec]

Cannot key the # sign on British keyboards ... It is located "above" '3' but you have to press the option key to get it, otherwise you would get the £. Unfortunately the option key seems to be ignored and whatever meta key combination is used, `3' gets echoed. (OS X Leopard on British Keyboard)

[gb]

Does it work to use ctrl-q first ? (E.g., ctrl-q meta-3 ?)

[verec]

Yes, ctrl-q followed by alt 3 does produce a # character. Though rewiring the user "muscle memory" to remember that alternate key binding when every single other OS X app honors alt-3 as a direct shortcut is a bit disappointing, don't you think?

Thanks

[jaj]

I can see that this would be a real problem for people using British keyboards. We could bind M-3 to insert #, but this would interfere with its use as a digit argument command. We could provide sample code to do this or make it a preference. Or we could detect if a British keyboard is being used and make it work in that case.

I'm sure there are many difficult key bindings for people with different keyboard layouts. Maybe the best solution is to prominently document how to customize the editor for cases like this.

I'm leaving it as a major defect for Cocoa IDE v1, but I'm changing the component to Documentation.

[rme]

r11917 in the trunk offers the, er, option of making the option key not act as meta. This would make option-3 work directly.

[rme]

Make M-3 insert a # character

[rme]

See the attached file for an example of how one might bind a command to M-3 to insert a # character.

[jhmcaleely]

I'm not clear. Will the default behaviour of the CCL IDE (in some future version) be to honour the keycaps on Mac OS keyboards (the # particularly in this case, but I'm sure there are others)?

I'm not happy with a resolution that means the keys on my keyboard (on a mac, especially) do not produce the characters printed on them by default.

I appreciate that some of the users of CCL may wish to take advantage of emacs like behaviour from the editor. If that is to be the default I'll stick with my Mac editor toolchain for lisp development.

[rme]

The issue boils down to what should be done with the option key. If you don't care about using key bindings with the meta modifier, then clear the "Use option as meta" checkbox in the general preferences, and the option key will work like it does normally. (You can still use the Esc key as meta in this case.)

If you like using the option key as meta modifier (for ease of typing C-M-f or whatever), then I was trying to point out a way you could still use option as meta, yet easily type a # character on a UK keyboard.

[gz]

I agree that it would be best to automatically detect the keyboard type and adjust the emacs bindings so that standard (in the CL sense) characters that are normally entered using option self-insert. I don't know if we can do that for v1, but that's certainly the long term goal.

[jhmcaleely]

This is a credibility bug for me, and I worry that it reveals a fundamental tension between wanting to support emacs and Mac GUIs.

If I type into a text box on the mac, and don't get the characters on my keycaps, I'm going to reject the application as ill-thought out, unless it prominently advertises that it expects me to know (and prefer) some legacy system. I do not feel that CCL currently advertises like that.

When I see such advertising on a Mac program, I walk away. When I want emacs, I'll use it (or one of the almost sympathetic ports like aquamacs), rather than some partial emulator.

[alms]

The repurposing of the option key did not create a credibility problem for MCL, which had the same default starting with its release in 1986. Note that we're just talking about the default. You can change the behavior at any time.

I don't recall any previous objections to this being the default setting for CCL or MCL. People certainly changed their own setups, but I don't recall previous suggestions that we change the default.

Granted, it's more of an issue for users of British keyboards. But I think that can be solved with documentation.

[jhmcaleely]

It is clearly a fair point that old users of this program will need some support (I only started using CCL in production around a year ago). Perhaps there are enough such users to make the case for this behaviour to be the default. However, my impression is that users of the CCL IDE must have been very patient in recent years. It may have been great in 1986 but it has been pretty unusable recently. MCL appears to me to have been without active support for some time, and to have missed most of the recent changes in Mac OS/OS X/lisp.

I'm reminded of the sign I saw on my college's mac lab (around 1994) when the students were required to do some programming in a non-mac application (I forget the language). 'Introduction to 'vi' for xxx-language. What are the middle two letters of evil?'. Just because mac users tolerate it, doesn't mean they like it.

If it is Clozure's position that the IDE supports this legacy option as the default, I will certainly not use the ide until it gains some features I find compelling.

My personal Macintosh environment includes US, UK and French keyboards, and I choose settings in the OS to manage these. I have no desire to learn how to teach a text editor things the OS already can tell it. Obviously if the IDE grows some particularly interesting featureset I will revisit the effort required to learn the IDE configuration. Right now, both emacs+slime or textmate+ccl-as-a-console-application are more compelling to me.

Speaking from the bigger picture, I would assume that people with a particular preference for emacs-like lisp ide's are well served by emacs and SLIME. it seems an odd strategic decision to try to emulate this, when there is a clear gap for a more mac-like IDE. IMHO, YMMV.

[gb]

One way to determine the name of the active keyboard input source is to use "Text Input Source Services" ( http://developer.apple.com/documentation/TextFonts/Reference/TextInputSourcesReference/Reference/reference.html), which apparently depends on Leopard or later; some NSInputManager may return similar information under Tiger but don't seem to work under Leopard. I don't know the exact details, but it seems that our ability to probe the runtime environment on startup and try to do a complicated version of the right thing might be limited.

If we indeed can't do much to automatically determine keyboard layout automatically and have to rely on the user to select a set of options that best suit their needs, then I'm starting to agree that it's preferable for the most pervasive of those options ("option-key-is-meta-key" or whatever it's called) to be off by default (for much the same reason that the similar option is off initially in Terminal.app.)

If the option key doesn't work as a meta key in Terminal, then as an Emacs user I'm mildly annoyed but familiar with the situation, and can grovel around through the preference panes until I find the right option, set it, and forget it; if I can't find the option, then I can grumble and use ESC prefixes. If I was a user of a keyboard layout that required the use of the option key to type standard characters and was not familiar with the situation, then yes, I can believe that my annoyance would be less mild if option-is-meta was on by default.

There are likely lots of useful behaviors in between option-is-always-meta and option-is-never-meta, but if we offer those behaviors it's not clear that we can default to them automatically. Minimizing the worst-case degree of annoyance and confusion seems like an important concern.

(Not getting "the meta key doesn't work!" bug reports is also an important concern, but at least those tickets wouldn't turn into ... whatever this one has turned into.)

[gz]

This is fixed (in the trunk) in r12169