From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Lennart Borgman (gmail)" Newsgroups: gmane.emacs.devel Subject: Re: A simple implementation of context-sensitive keys Date: Thu, 11 Sep 2008 15:41:56 +0200 Message-ID: <48C92024.6080804@gmail.com> References: <87y72079mg.fsf@thinkpad.tsdh.de> <87d4jbg62j.fsf@thinkpad.tsdh.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1221140880 22420 80.91.229.12 (11 Sep 2008 13:48:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 11 Sep 2008 13:48:00 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier , Tassilo Horn Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 11 15:48:46 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KdmX5-00010x-73 for ged-emacs-devel@m.gmane.org; Thu, 11 Sep 2008 15:48:28 +0200 Original-Received: from localhost ([127.0.0.1]:48304 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KdmW5-0002Et-0z for ged-emacs-devel@m.gmane.org; Thu, 11 Sep 2008 09:47:25 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KdmR3-0008GS-78 for emacs-devel@gnu.org; Thu, 11 Sep 2008 09:42:13 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KdmR1-0008FO-F8 for emacs-devel@gnu.org; Thu, 11 Sep 2008 09:42:11 -0400 Original-Received: from [199.232.76.173] (port=37222 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KdmR1-0008FE-6Y for emacs-devel@gnu.org; Thu, 11 Sep 2008 09:42:11 -0400 Original-Received: from ch-smtp02.sth.basefarm.net ([80.76.149.213]:51641) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KdmR0-0001f9-Ax for emacs-devel@gnu.org; Thu, 11 Sep 2008 09:42:10 -0400 Original-Received: from c83-254-151-87.bredband.comhem.se ([83.254.151.87]:61419 helo=[127.0.0.1]) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1KdmQx-0007bo-7H; Thu, 11 Sep 2008 15:42:07 +0200 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666 In-Reply-To: X-Enigmail-Version: 0.95.7 X-Antivirus: avast! (VPS 080911-0, 2008-09-11), Outbound message X-Antivirus-Status: Clean X-Originating-IP: 83.254.151.87 X-Scan-Result: No virus found in message 1KdmQx-0007bo-7H. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1KdmQx-0007bo-7H 628a706b5a2f1d75f7c0c2381d935838 X-detected-kernel: by monty-python.gnu.org: Linux 2.6? (barebone, rare!) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:103809 Archived-At: Stefan Monnier wrote: >>> In any case, the main problem with such things (whichever way they're >>> implemented) is that the rest of Emacs doesn't know and/or expect such >>> condition bindings, so C-h k gives only partial information, and >>> similarly where-is doesn't know how to tell the whole story. > >> Sure, so I'd say that in general modes shouldn't use such facilities by >> default. Which commands should be executed depending on which context >> is a quite subjective decision anyway. But to have the possibilities >> right at hand is great, whichever one you use. > > I hope we can do better than that, i.e. come up with a way to do > something like what you proposed, but still have where-is, C-h k, > etc... take it into account. I am starting to wonder whether this is the right way to go. As I said something reminding of this is done in smart-tab, tabkey2 and hippie-expand. But all these are kind of brute force method to handle the frustrating situations with the many uncoordinated completion alternatives there are. And actually I find that special use useful. However before doing what Tassilo suggest I think it would be better to look at the background for it. If I understand it correctly the problem is at least partly how the keymaps for minor modes cooperates. If they do have the same key binding then we have the question which one should be used. And that may very well happen since their is no mechanism at all to prevent it. Currently the problem of which minor mode gets the key press is resolved just by the corresponding minor mode's position in minor-mode-map-alist. The first one gets it. There is no notion in where-is, C-h k, etc that there is any key binding conflict. There is no easy way for users to reorder minor-mode-map-alist. I think this is where we should start. And after that come back to Tassilo's suggestion.