From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?ISO-8859-1?Q?Andreas_R=F6hler?= Newsgroups: gmane.emacs.devel Subject: Re: over-engineered (and under-standardized) inferior interfaces Date: Fri, 22 Aug 2014 07:57:11 +0200 Message-ID: <53F6DBB7.1030803@online.de> References: <20140821232158.3d0aea56@forcix> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1408687099 7930 80.91.229.3 (22 Aug 2014 05:58:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 22 Aug 2014 05:58:19 +0000 (UTC) Cc: Emacs developers To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 22 07:58:13 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XKhrT-0000Vz-IZ for ged-emacs-devel@m.gmane.org; Fri, 22 Aug 2014 07:58:07 +0200 Original-Received: from localhost ([::1]:35231 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKhrT-000551-9P for ged-emacs-devel@m.gmane.org; Fri, 22 Aug 2014 01:58:07 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42615) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKhrC-00054t-9R for emacs-devel@gnu.org; Fri, 22 Aug 2014 01:57:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XKhr6-0006jk-5i for emacs-devel@gnu.org; Fri, 22 Aug 2014 01:57:50 -0400 Original-Received: from mout.kundenserver.de ([212.227.17.13]:61536) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKhr5-0006jg-Sp for emacs-devel@gnu.org; Fri, 22 Aug 2014 01:57:44 -0400 Original-Received: from [192.168.178.32] (brln-4dba40ca.pool.mediaWays.net [77.186.64.202]) by mrelayeu.kundenserver.de (node=mreue101) with ESMTP (Nemesis) id 0M4qlR-1WQegi1mbl-00yvF9; Fri, 22 Aug 2014 07:57:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Icedove/24.7.0 In-Reply-To: X-Provags-ID: V02:K0:CTaK+sbJ42tExUHV83Hnyk2HVeBwAJBtKWNmNn8H72l qVdeMydRWQMvDLwbIWnqGb2r6Nr5CA7hKZInzcrPp0q1pIBcku TkkJ4OyAEODLHt79Z7nEpwfkU95CU5njfrNwqXWFgqzhMfUs4G I+LLPBwKCbIFKNITapCkxG6eNdQRYuP1Ca7TBpAT1vQGjeFH1K eCWkVFNvDiTTJeRZEjtCfx/ziBMPWPYXwKHrY63SXFgRtCaLRJ NvcEJl3L3p0ehzktHjpiqofCNPx7FUsMSLDRHcYWTe+DN6kZtJ LjCmLSqFGZnrygoGB3R7SKqy5+yYCe3/2b65vTFopjYHzKBbhJ Hgjbou/U8ZKpj7xRKlNVgFW0SdgbUQOhkC8xwLxTJ X-UI-Out-Filterresults: notjunk:1; X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 212.227.17.13 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:173803 Archived-At: On 22.08.2014 05:45, Stefan Monnier wrote: >> Just some comments on the default bindings. I understand these are the >> historically-available ones, but I do feel that if we create a new mode >> like this, it might be worthwhile to rethink them. > > Sure. prog-proc-mode is really just an experiment, and I'm quite open > to changes, both in terms of UI and implementation. > >> With the availability of an "active region", I think it would be nice >> to consolidate send-buffer and send-region to a single binding. > > Fine. > >> Using a nice binding like C-c C-c for a somewhat less-common command >> like "compile the current file in the REPL" (as opposed to using M-x >> (re)compile) seems like a waste. > > FWIW under sml-mode, C-c C-c runs a "make"-like command (but it's > a command passed to the inferior process rather than being a separate > process like in M-x compile). > >> So I'd suggest using C-c C-c for a new prog-proc-send-region-or-buffer. > > I think "send the current buffer" is not good enough, except for those > rare systems where a single file is all you need. > >> I'm also unsure about using up too many C-c C-X bindings in this minor >> mode; the major mode that activates it won't be able to easily override >> those bindings locally, so it might be a good idea to be a bit more >> conservative with the default bindings, providing the commands but not >> the bindings for the less common use cases (load, compile, region, >> buffer). > > My memory failed me: if you look at the code, you'll see that > prog-proc-mode is not a minor mode but a major-mode, to be used as > parent mode (in place of prog-mode, from which it derives). > So major modes can very easily override those bindings. > But yes: we shouldn't use too many such bindings. > > > Stefan > > Hi, very interesting move, thanks all. Started some weeks o project "general-key", which seems to point into the very same direction. Below the README: [...] For common items like `line', `word' or `symbol' Emacs' language modes commonly don't touch the keybinding. That way `backward-word', `copy-word', `forward-word', `kill-word', `mark-word' etc. don't need configuration. However, with programming, there are a couple of common cases, not dealt with yet. - statements, for example assigments - conditionals resp. loops - combinations of that, i.e. functions for example WRT to function we might have for all modes `general-key-function-backward' `general-key-function-copy' `general-key-function-forward' `general-key-function-kill' `general-key-function-mark' If general-key-mode provides key-binding for basic types, these keys must not be changed or configured again by language-modes. Now it would be at the modes, for example WRT python-mode.el: (setq general-key-function-backward 'py-backward-def-or-class) (setq general-key-function-copy 'py-copy-def-or-class) (setq general-key-function-forward 'py-forward-def-or-class) (setq general-key-function-kill 'py-kill-def-or-class) (setq general-key-function-mark 'py-mark-def-or-class) Respective with block, statement and expression maybe. (setq general-key-block-backward 'py-backward-block) ... A second group of commands simplified that way deals with braces, brakcets, parenthesis or does a trim. (setq general-key-region-brace 'ar-brace-region-atpt) (setq general-key-region-bracket 'ar-bracket-region-atpt) (setq general-key-region-trim 'ar-trim-region-atpt) (setq general-key-region-parentize 'ar-parentize-region-atpt) If a region might be braced, parenthized etc. in a suitable way, these objects also should be easy to mark, copy, delete resp. kill and moved on: Here an example using the parentized form: (setq general-key-parentized-backward 'ar-beginning-of-parentized-atpt) (setq general-key-parentized-copy 'ar-copy-parentized-atpt) (setq general-key-parentized-trim 'ar-trim-parentized-atpt) (setq general-key-parentized-forward 'ar-forward-parentized-atpt) (setq general-key-parentized-kill 'ar-kill-parentized-atpt) (setq general-key-parentized-mark 'ar-mark-parentized-atpt) ;;;;;;; Cheers, Andreas http://bazaar.launchpad.net/~a-roehler/s-x-emacs-werkstatt