From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: completion-list-mode-map Date: Wed, 06 Jul 2011 08:49:56 -0400 Message-ID: References: <4DEA3F21.2020302@gmail.com> <4E07B9F0.3080102@gmail.com> <4E0F40A1.3020503@gmail.com> <4E0FB543.9040608@gmail.com> <4E13BC5A.2070007@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1309959383 6095 80.91.229.12 (6 Jul 2011 13:36:23 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 6 Jul 2011 13:36:23 +0000 (UTC) Cc: emacs-devel@gnu.org To: Christoph Scholtes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 06 15:36:19 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QeSH4-0003BU-Li for ged-emacs-devel@m.gmane.org; Wed, 06 Jul 2011 15:36:18 +0200 Original-Received: from localhost ([::1]:34157 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QeSH3-0005YR-FX for ged-emacs-devel@m.gmane.org; Wed, 06 Jul 2011 09:36:17 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:42295) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QeRYH-0001Yz-RK for emacs-devel@gnu.org; Wed, 06 Jul 2011 08:50:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QeRYF-0001wp-P9 for emacs-devel@gnu.org; Wed, 06 Jul 2011 08:50:01 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:48520 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QeRYF-0001wS-57 for emacs-devel@gnu.org; Wed, 06 Jul 2011 08:49:59 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFxZFE5FxIV4/2dsb2JhbABTqAJ4iHrDWYY2BJ5rhC4 X-IronPort-AV: E=Sophos;i="4.65,486,1304308800"; d="scan'208";a="120648507" Original-Received: from 69-196-133-120.dsl.teksavvy.com (HELO ceviche.home) ([69.196.133.120]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 06 Jul 2011 08:49:56 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 8131C660DD; Wed, 6 Jul 2011 08:49:56 -0400 (EDT) In-Reply-To: <4E13BC5A.2070007@gmail.com> (Christoph Scholtes's message of "Tue, 05 Jul 2011 19:37:30 -0600") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.183 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:141648 Archived-At: >>> or is there implicit inheritance of the keymap when deriving from >>> special mode? >> Yes, that inheritance is implicit (it's set up when the mode is >> activated) unless the keymap already has a parent. > I started looking into this and it looks like it is more complicated than > I thought. I grepped for `'mode-class 'special' and got a pageful of > hits. Some of these modes are already derived from special modes, some are > not. Looking at the ones that are not, I am wondering if they should be. Note: if a mode derives from special-mode, then it does not need the (put 'foo-mode 'mode-class 'special). > - arc-mode's mode-class is special. However, arc-mode is not derived from > special-mode. Should it be? The general rule should be that it is, but check that it's compatible. Basically special-mode has a read-only buffer and some standard key-bindings, so as long as there's no deep conflict in the key-bindings and the mode is read-only, it should derive. For this reason I think arc-mode should derive from special-mode. > - comint-mode is derived from fundamental-mode, but it's mode-class is also > special. Should it be derived from special-mode instead? Here on the other hand, we have some clear conflicts: comint-mode is not read-only and can't bind `q' to quit-window and `g' to revert-buffer. So I don't think it should inherit from special-mode. > In other cases modes derive from special-mode already, but the key map > parent is not set to special-mode map. For example, tar-mode. Should the key > map parent always be special-mode-map? define-derived-mode will set the keymap parent to special-mode-map if the mode's keymap doesn't already have a parent. > What prompted me to look into this in the first place was the inconsistent > behavior of `q'/`z' when trying to quit/kill buffers. special-mode map > defines `q' as quit-window and `z' as kill-this-buffer, but some keymaps > define `q' as, for example, thumbs-kill-buffer. How do we handle > these cases? (One of) the purposes of special-mode is to standardize key bindings, so I think that thumbs-kill-buffer will have to go: it does something similar to quit-window, and the differences are just an annoyance. In other cases, the key-binding conflicts may need to be resolved by finding new keys, rather than just ditching the old binding. Stefan