From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: Emacs User Friendliness Question/Hope Date: Sat, 17 Jul 2010 05:08:19 +0200 Message-ID: <87mxtq7ql8.fsf@telefonica.net> References: <1279277325.2135.114.camel@logrus.localdomain> <1279290657.2135.131.camel@logrus.localdomain> <4C410A4C.3070508@gmail.com> <87k4ou26yc.fsf@catnip.gol.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1279336122 16723 80.91.229.12 (17 Jul 2010 03:08:42 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 17 Jul 2010 03:08:42 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 17 05:08:41 2010 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.69) (envelope-from ) id 1OZxlW-0005Sj-Vm for ged-emacs-devel@m.gmane.org; Sat, 17 Jul 2010 05:08:39 +0200 Original-Received: from localhost ([127.0.0.1]:53963 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OZxlW-00046a-Ao for ged-emacs-devel@m.gmane.org; Fri, 16 Jul 2010 23:08:38 -0400 Original-Received: from [140.186.70.92] (port=41058 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OZxlR-00045i-EI for emacs-devel@gnu.org; Fri, 16 Jul 2010 23:08:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OZxlQ-0003ha-AB for emacs-devel@gnu.org; Fri, 16 Jul 2010 23:08:33 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:33808) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZxlP-0003hT-Ua for emacs-devel@gnu.org; Fri, 16 Jul 2010 23:08:32 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OZxlL-0005Q2-Tf for emacs-devel@gnu.org; Sat, 17 Jul 2010 05:08:27 +0200 Original-Received: from 83.42.13.171 ([83.42.13.171]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 17 Jul 2010 05:08:27 +0200 Original-Received: from ofv by 83.42.13.171 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 17 Jul 2010 05:08:27 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 52 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 83.42.13.171 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:p3IVXRWWIq1Xo0ISVHIlLgpbpGM= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:127475 Archived-At: Miles Bader writes: > Christoph writes: >> In order to help increasing the "user-friendliness" couldn't we do >> something similar to what viper-mode does? I.e. provide different levels >> of "Emacs-ness". >> >> The lowest level (default?) could enable features that are common among >> other editors/IDEs, e.g. CUA. Increasing levels could "unlock" more and >> more "Emacs-ness" up to the point of where you get what everybody would >> consider the "true" Emacs in all its glory. > > You'd have to be much more specific. > > This seems like the sort of idea that's attractive when stated vaguely > with lots of hand-waving, but would be very hard to actually make work > in practice. > > What "levels" would there be, exactly? What bindings would be different > in each level? How would you avoid conflicts between "traditional" > Emacs bindings and CUA bindings? How would your scheme work in the > presence of 3rd-party packages? Would your scheme discourage people > from learning Emacs bindings? > > As I mentioned in a previous message on this thread, cua-mode, which has > fairly limited goals, has to use extremely kludgey methods to achieve > them. Something considerably more elaborate would probably have an even > harder time. I possible solution for this problem is to use `actions'. An action is a generic concept like `fordward-line', or `undo', or `save', or `yank' (`paste', if you prefer.) `universal-argument', `execute-extended-command' and `C-x' (whatever is officially called on Emacs jargon) would be actions as well. Currently a mode defines its keymap relating keys to functions. An action-aware mode relates actions to functions. At a higher level, there is a mapping of keys into actions. When a mode is activated for a buffer, the keymap is constructed looking up the corresponding keys assigned to the actions the mode implements. A mode inherits the key->action mapping from its parent mode, but can define its own actions that overrides its parent's. The legacy code that defines keymaps keeps working. local-set-key keeps working as well. There could be a "classic-emacs" key->action mapping, a "cua" one, etc. Of course those mappings could collide with some keymaps defined on legacy code, but nothing is perfect, and Emacs could inform the user about that circumstance when the legacy keymap is activated. This can be extended to menus and buttons on the toolbar, so a button that implements an action is useful for all modes that support that action.