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: over-engineered (and under-standardized) inferior interfaces Date: Thu, 21 Aug 2014 23:45:49 -0400 Message-ID: References: <20140821232158.3d0aea56@forcix> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1408679178 25574 80.91.229.3 (22 Aug 2014 03:46:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 22 Aug 2014 03:46:18 +0000 (UTC) Cc: emacs-devel@gnu.org To: Jorgen Schaefer Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 22 05:46:11 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 1XKfnj-0001oA-Q0 for ged-emacs-devel@m.gmane.org; Fri, 22 Aug 2014 05:46:07 +0200 Original-Received: from localhost ([::1]:34980 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKfnj-0004ab-Dm for ged-emacs-devel@m.gmane.org; Thu, 21 Aug 2014 23:46:07 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57618) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKfnZ-0004Zb-VU for emacs-devel@gnu.org; Thu, 21 Aug 2014 23:46:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XKfnS-0005na-Bv for emacs-devel@gnu.org; Thu, 21 Aug 2014 23:45:57 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:9831) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKfnS-0005nW-88 for emacs-devel@gnu.org; Thu, 21 Aug 2014 23:45:50 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUGAIDvNVPAqyKr/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCwsOJhIUGA0kiAQI0hkXjnoHhDgEqwODTCE X-IPAS-Result: ArUGAIDvNVPAqyKr/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCwsOJhIUGA0kiAQI0hkXjnoHhDgEqwODTCE X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="87426868" Original-Received: from 192-171-34-171.cpe.pppoe.ca (HELO pastel.home) ([192.171.34.171]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Aug 2014 23:45:49 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 3106362EE2; Thu, 21 Aug 2014 23:45:49 -0400 (EDT) In-Reply-To: <20140821232158.3d0aea56@forcix> (Jorgen Schaefer's message of "Thu, 21 Aug 2014 23:21:58 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:173801 Archived-At: > 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