Opened 13 years ago

Closed 12 years ago

#182 closed defect (fixed)

Cannot enter # on British Keyboard

Reported by: verec Owned by: rme
Priority: major Milestone: Cocoa IDE v1
Component: Documentation Version: pre-1.0
Keywords: keyboard mapping Cc:


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)

Attachments (1)

insert-sharp.lisp (364 bytes) - added by rme 12 years ago.
Make M-3 insert a # character

Download all attachments as: .zip

Change History (15)

comment:1 Changed 13 years ago by gb

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

comment:2 Changed 13 years ago by 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?


comment:3 Changed 12 years ago by jaj

  • Component changed from IDE to Documentation
  • Milestone set to Cocoa IDE v1

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.

comment:4 Changed 12 years ago by rme

  • Owner changed from gb to rme
  • Status changed from new to assigned

comment:5 Changed 12 years ago by 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.

Changed 12 years ago by rme

Make M-3 insert a # character

comment:6 Changed 12 years ago by rme

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

comment:7 Changed 12 years ago by 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.

comment:8 Changed 12 years ago by 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.

comment:9 Changed 12 years ago by 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.

comment:10 Changed 12 years ago by 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.

comment:11 Changed 12 years ago by 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.

comment:12 Changed 12 years ago by 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.

comment:13 Changed 12 years ago by gb

One way to determine the name of the active keyboard input source is to use "Text Input Source Services" (, 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

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.)

comment:14 Changed 12 years ago by gz

  • Resolution set to fixed
  • Status changed from assigned to closed

This is fixed (in the trunk) in r12169

Note: See TracTickets for help on using tickets.