From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Stefan Monnier" Newsgroups: gmane.emacs.help Subject: Re: global-set-key [? =?utf-8?b?XCBNLcO2?=] Date: 28 May 2003 13:53:12 -0400 Organization: Yale University Sender: help-gnu-emacs-bounces+gnu-help-gnu-emacs=m.gmane.org@gnu.org Message-ID: <5ln0h7q7p3.fsf@rum.cs.yale.edu> References: <3EC936AD.41BBBEC8@gmx.net> <87of1ybr5p.fsf@bach.composers> <3ECB2DA2.107EDA4@gmx.net> <5lr86o8jox.fsf@rum.cs.yale.edu> <5l4r3frv9z.fsf@rum.cs.yale.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: main.gmane.org 1054145234 24851 80.91.224.249 (28 May 2003 18:07:14 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 28 May 2003 18:07:14 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+gnu-help-gnu-emacs=m.gmane.org@gnu.org Wed May 28 20:07:06 2003 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19L5KK-0006Ru-00 for ; Wed, 28 May 2003 20:07:05 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.20) id 19L5Jn-0003Iw-Gl for gnu-help-gnu-emacs@m.gmane.org; Wed, 28 May 2003 14:06:31 -0400 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!logbridge.uoregon.edu!canoe.uoregon.edu!news.wss.yale.edu!rum.cs.yale.edu!rum.cs.yale.edu Original-Newsgroups: gnu.emacs.help Original-Lines: 50 Original-NNTP-Posting-Host: rum.cs.yale.edu Original-X-Trace: news.wss.yale.edu 1054144396 18980 128.36.229.169 (28 May 2003 17:53:16 GMT) Original-X-Complaints-To: news@news.wss.yale.edu Original-NNTP-Posting-Date: Wed, 28 May 2003 17:53:16 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-Original-NNTP-Posting-Host: rum.cs.yale.edu X-Original-Trace: 28 May 2003 13:53:12 -0400, rum.cs.yale.edu Original-Xref: shelby.stanford.edu gnu.emacs.help:113801 Original-To: help-gnu-emacs@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: help-gnu-emacs-bounces+gnu-help-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.help:10296 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:10296 > Yes, but the bug might be a design bug. If that is so, we cannot tell > users "please wait for a few years until we redesign the darn thing." Of course, but I haven't seen such a thing w.r.t binding-non-ASCII-keys and unibyte. >> In the OP's case, I'm pretty sure the problem is that Emacs does not >> properly set the keyboard coding-system. > IIRC, there's more here than meets the eye. Binding non-ASCII keys in > a .emacs requires that (a) Emacs reads the key correctly from the init > file and converts it to the internal representation that the user > meant, and (b) that keyboard decoding produces a code that matches > what was read from the init file. It could be a bit tricky to satisfy > both in a given language environment, since .emacs files generally > don't have coding cookies. We're talking about adding a unibyte-cookie, right ? So we can assume that adding a coding-cookie is an acceptable cost if it saves us from a unibyte-cookie. > Also, if I'm not mistaken, non-ASCII keys > with modifiers are very hard to express unless you go unibyte. I've never heard of any such difficulty. [?\M-é] works fine here. Oh wait, you're probably referring to "\M-é", which probably won't work, indeed. But the "keys in a string" thingy should best be forgotten anyway: either use a vector or use `kbd'. >> I don't think the manual should encourage to use workarounds (e.g. set >> the unibyte:t cookie in your .emacs) rather than real fixes (set the >> keyboard coding system properly). > Unless setting keyboard coding system doesn't always solve the > problem, that is. Setting the unibyte cookie doesn't either always solve the problem. Right now I know of no case where setting the unibyte cookie solves the problem while setting the keyboard-coding-system doesn't, which is why I suggest we recommend setting the keyboard-coding-system. Of course, there might be cases where a unibyte-keyboard with unibyte-.emacs works better, but I haven't seen them yet. Stefan PS: BTW, when I say keyboard-coding-system I also mean locale-coding-system (since that's what is used in X and in W32 for the keyboard events).