From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Josh Newsgroups: gmane.emacs.devel Subject: Re: Default behaviour of RET. Date: Tue, 22 Oct 2013 21:36:21 -0700 Message-ID: References: <8361sqli02.fsf@gnu.org> <1730ebf3-db44-498c-b2a9-4d288d83a946@default> <87k3h6xuen.fsf@yandex.ru> <1878e4fa-50f2-4655-a4ff-30d1db708ee8@default> <5D2595BD-AC11-4FB6-B363-31EBE28A0AE0@mit.edu> <20131022005911.63239c56@forcix.kollektiv-hamburg.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: ger.gmane.org 1382503026 21200 80.91.229.3 (23 Oct 2013 04:37:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Oct 2013 04:37:06 +0000 (UTC) Cc: chad , "emacs-devel@gnu.org devel" , Jorgen Schaefer To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 23 06:37:09 2013 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 1VYqBt-0004fD-6Y for ged-emacs-devel@m.gmane.org; Wed, 23 Oct 2013 06:37:05 +0200 Original-Received: from localhost ([::1]:47623 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VYqBs-00052S-Qj for ged-emacs-devel@m.gmane.org; Wed, 23 Oct 2013 00:37:04 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50077) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VYqBm-00052J-6F for emacs-devel@gnu.org; Wed, 23 Oct 2013 00:37:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VYqBh-0006oj-Dm for emacs-devel@gnu.org; Wed, 23 Oct 2013 00:36:58 -0400 Original-Received: from mail-wg0-f44.google.com ([74.125.82.44]:32808) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VYqBh-0006nk-7b for emacs-devel@gnu.org; Wed, 23 Oct 2013 00:36:53 -0400 Original-Received: by mail-wg0-f44.google.com with SMTP id n12so229397wgh.11 for ; Tue, 22 Oct 2013 21:36:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=IRrLnOdLLVN37Kdbvas1fkHbL99IO/OupHEH1dH5zko=; b=Y4TD1l7HRpa69ke2IOetsivUH8XRoWy8swPLE357KzxhCLRWFuNnEKcDitmBdmCKz+ hioaHZlMvmFgR+w/igdflulXbOt4qUfmk2FHqDi8nZm3HV/zY82rmKRydeJXy8dbkKao z28FssEmpyQq3Na0oo+xTU/fprkTJdbA5tIDSmJD/i5oz2n98LASzjiHk71UAA4pttOv IgDhkNfhKmcsLtTaChqTwLmO6YDUCPbt9z1vvAHuuHMFX1Ag3p0rm/wS1fQs32RwKfVh pPvQ129ETUPvoVHjhfbTAvqv9e1gcg8agraFv2MKLdCkERuJcVvX2++5CmswZn7iiiKO FYiw== X-Gm-Message-State: ALoCoQkP7dR5yMlax1sqVMVK8x3+i2wOuWniZm+eqeHLzB92etFidNA2NrHDkaA/6V/BIJEvr7K+ X-Received: by 10.180.188.197 with SMTP id gc5mr277939wic.42.1382503011938; Tue, 22 Oct 2013 21:36:51 -0700 (PDT) Original-Received: by 10.194.22.225 with HTTP; Tue, 22 Oct 2013 21:36:21 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: 62D_5d6etZvznlOlvrsNmpfAj8E X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 74.125.82.44 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:164469 Archived-At: On Tue, Oct 22, 2013 at 7:02 AM, Stefan Monnier wrote: >> If the default binding of RET changes, please do make sure that there >> is a simple and easily accessible way of toggling this, to enable >> correct pasting of multi-line text in tty versions of Emacs. > > Indeed, very good point. > So we have the following issues if we want to enable electric-indent-mode: > - C-j's default binding becomes useless. > - need for a new tty-paste command. I'm not sure that follows. In visual-line-mode, the problem of how to specialize functions' interactive behavior while leaving their programmatic behavior unchanged is solved thusly: (defvar visual-line-mode-map (let ((map (make-sparse-keymap))) (define-key map [remap kill-line] 'kill-visual-line) (define-key map [remap move-beginning-of-line] 'beginning-of-visual-line) ... map)) Is there some reason why electric-mode could not employ a similar approach using a new electric-mode-map, for example by removing ?\n from electric-indent-chars and remapping newline to newline-and-indent? Alternatively, electric-mode could abandon use of post-self-insert-hook entirely, instead remapping self-insert-command to a new self-insert-and-reindent-command that would first perform the insertion as usual and then reindent iff electric-indent-chars contained the inserted character. Both of these approaches would perform electric reindentation after interactive newline insertion while leaving the newline function's programmatic behavior unchanged. If electric-mode were enabled by default for programming modes, both of these approaches would also result in the "modern" reindentation behavior advocated by many here without the necessity of any changes to default key bindings. Josh