From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Fredrik Staxeng Newsgroups: gmane.emacs.help Subject: Re: M-TAB already used by KDE Date: 19 Dec 2002 12:59:16 +0100 Sender: help-gnu-emacs-bounces+gnu-help-gnu-emacs=m.gmane.org@gnu.org Message-ID: <1m8yymqkx7.fsf@Tempo.Update.UU.SE> References: <3dfe3ea4.1245206@news.cis.dfn.de> <1my96ndvtq.fsf@Tempo.Update.UU.SE> <1mr8cfq9uv.fsf@Tempo.Update.UU.SE> <84ptry4g6v.fsf@lucy.cs.uni-dortmund.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: main.gmane.org 1040299237 9457 80.91.224.249 (19 Dec 2002 12:00:37 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 19 Dec 2002 12:00:37 +0000 (UTC) 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 18OzLp-0002Rq-00 for ; Thu, 19 Dec 2002 13:00:29 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18OzM2-00050n-00 for gnu-help-gnu-emacs@m.gmane.org; Thu, 19 Dec 2002 07:00:42 -0500 Original-Newsgroups: comp.emacs,gnu.emacs.help Original-Lines: 97 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2 Original-NNTP-Posting-Host: news.update.uu.se Original-X-Trace: puffinus.its.uu.se 1040298194 news.update.uu.se (19 Dec 2002 12:43:14 +0100) Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!news.tele.dk!news.tele.dk!small.news.tele.dk!news.algonet.se!newsfeed1.telenordia.se!algonet!uab.ericsson.se!erix.ericsson.se!erinews.ericsson.se!newsfeed.sunet.se!news01.sunet.se!puffinus.its.uu.se Original-Xref: shelby.stanford.edu comp.emacs:76545 gnu.emacs.help:108293 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:4822 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:4822 kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes: >Fredrik Staxeng writes: > >> kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes: >> >>>Really? Hm. I've seen some Alt bindings here and there... >> >> I have only seen iso-transl. But binding Alt instead of Meta assumes that >> Alt is distinct from Meta. > >Of course! And so provides a clue as to which keyboard the perpetrator has. :-) >> The best any program can do, is to use only one modifier, and make both >> Alt and Meta invoke that modifier. Of course, there should be a way to >> use the full capability of _any_ keyboard. But because of the historical >> mistakes, it can't be done "out-of-the-box". > >Yes, you've said that before. I understand. But I'm not sure if I >agree. I have to think about it further. I think that the overriding goal is to make the keys adjacent to the space bar work as Meta. I have used Emacs without a Meta key for a couple of thousand hours, and the Emacs command set doesn't really work well without it. I can't see another way to do that, given that some X servers send Meta for that key, and some X servers send Alt. The ICCCM method of looking for Meta keysyms in the modifier map means that Meta functions move to the Windows key, _if_ you use the pc104 keymap. If you use the pc101 keymap, the Meta functions are on the Alt key. If you spill coffee on your pc104 keyboard and plug in your old pc101 keyboard, you have no access to Meta functions at all. If this had been done sensibly, the pc104 would be a strict superset of pc101 behaviourally. Then Linux distributions could use pc104 as the default in the knowledge that it works even with pc101 keyboards. >> If the default of x-meta-keysym is '(meta alt), then I am happy. > >Now that you bring it up, it would be a good idea to allow lists >instead of just symbols. But that isn't implemented yet. What problem was this intended to solve then? >> A minor quibble: I think that the x-alt-keysym is superfluous, >> and only serves to perpetrate the confusion. > >=8-{ > >The alt, hyper, meta, super modifiers are very similar, only the >degree of usage differs. So why would any of these variables be >superfluous? Key names are just labels. What matters is the mapping from key position to behaviour. The Emacs command set is designed with the expectation that there is a shift-like modifier key that is given the name Meta. In reality, very few keyboards provide a key labeled Meta, but they provide a convenient substitute. It's labeled Alt on PC keyboards, and it is labeled <> on Sun keyboards. Sun users know that their Alt key is not the same as the PC Alt key, but PC users generally do not know the details of Sun keyboards. They are used to that Alt is synonymous with Meta. Introducing a different concept with the same name into Emacs is confusing. On the other hand, Super and Hyper are unambigously distinct from Meta/Alt. That is, instead of putting mappings on Alt, which assumes a Sun keyboard, put them on Super. I suggested that Meta and Alt should be treated synoumously by default, and that there should be two settings, x-meta-is-super and x-alt-is-super. Then all users will have the keys adjacent to the space bar as working meta keys. Then, the iso-transl Alt mappings are moved to Super. Sun users can then put (setq x-alt-is-super t) in their .emacs to access those bindings, and KDE users can use (setq x-meta-is-super t) to do the same thing. Or they could make the key send Super, and not change Emacs at all. Your solution strikes me as a bit overengineered. I don't see the need for full generality here, especially since there are two (or three) other general layers (xkb, xmodmap and Emacs keymaps). The solution above is simpler to understand and use for the common practical cases I can imagine. If you really want full generality, the most powerful solution would be a x-key-translate-hook. -- Fredrik Stax\"ang | rot13: sfgk@hcqngr.hh.fr