From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Multi-line input (was: Losing minibuffer input) Date: Fri, 05 Dec 2014 02:38:03 +0200 Organization: LINKOV.NET Message-ID: <87oarjklgc.fsf_-_@mail.linkov.net> References: <87fvds2r5i.fsf@mail.jurta.org> <87zjbokx0t.fsf@mail.linkov.net> <546E1845.2010301@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1417740872 9892 80.91.229.3 (5 Dec 2014 00:54:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 5 Dec 2014 00:54:32 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 05 01:54:27 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 1XwhAB-0000q3-69 for ged-emacs-devel@m.gmane.org; Fri, 05 Dec 2014 01:54:27 +0100 Original-Received: from localhost ([::1]:48329 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XwhAA-0004Ka-Q2 for ged-emacs-devel@m.gmane.org; Thu, 04 Dec 2014 19:54:26 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37460) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XwhA1-0004K4-8l for emacs-devel@gnu.org; Thu, 04 Dec 2014 19:54:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xwh9v-0001Ss-3V for emacs-devel@gnu.org; Thu, 04 Dec 2014 19:54:17 -0500 Original-Received: from ps18281.dreamhost.com ([69.163.222.226]:55109 helo=ps18281.dreamhostps.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xwh9u-0001Si-Rm for emacs-devel@gnu.org; Thu, 04 Dec 2014 19:54:11 -0500 Original-Received: from localhost.linkov.net (ps18281.dreamhostps.com [69.163.222.226]) by ps18281.dreamhostps.com (Postfix) with ESMTP id 45E1A348328E73; Thu, 4 Dec 2014 16:54:10 -0800 (PST) In-Reply-To: <546E1845.2010301@dancol.org> (Daniel Colascione's message of "Thu, 20 Nov 2014 08:35:17 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (x86_64-pc-linux-gnu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 69.163.222.226 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:178865 Archived-At: > S-RET is a good idea; I've seen this keybinding used in lots of other > programs for "insert a newline without executing an action". Other problematic place where S-RET could help to insert a newline is shell input. What is worse in shell than in the minibuffer typing RET accidentally in the middle of multi-line shell input causes a mess: it sends the part before point, and leaves the remaining lines dangling at the end of the shell buffer. This patch gets the input until the end of the possibly multi-line input field instead of only the end of the line: diff --git a/lisp/comint.el b/lisp/comint.el index da37827..da21d66 100644 --- a/lisp/comint.el +++ b/lisp/comint.el @@ -457,6 +457,7 @@ (defvar comint-mode-map (define-key map [?\C-c ?\M-s] 'comint-next-matching-input-from-input) (define-key map "\e\C-l" 'comint-show-output) (define-key map "\C-m" 'comint-send-input) + (define-key map [S-return] 'newline) (define-key map "\C-d" 'comint-delchar-or-maybe-eof) ;; The following two are standardly bound to delete-forward-char, ;; but they should never do EOF, just delete. @@ -1781,7 +1782,7 @@ (defun comint-send-input (&optional no-newline artificial) (widen) (let* ((pmark (process-mark proc)) (intxt (if (>= (point) (marker-position pmark)) - (progn (if comint-eol-on-send (end-of-line)) + (progn (if comint-eol-on-send (goto-char (field-end))) (buffer-substring pmark (point))) (let ((copy (funcall comint-get-old-input))) (goto-char pmark) While checking this, I also noticed a problem in searching the history of multi-line entries. `comint-line-beginning-position' operates only on the current line, so it too should be replaced with `field-beginning': diff --git a/lisp/comint.el b/lisp/comint.el index da37827..da21d66 100644 --- a/lisp/comint.el +++ b/lisp/comint.el @@ -1475,7 +1476,7 @@ (defun comint-history-isearch-search () (or ;; 1. First try searching in the initial comint text (funcall search-fun string - (if isearch-forward bound (comint-line-beginning-position)) + (if isearch-forward bound (field-beginning)) noerror) ;; 2. If the above search fails, start putting next/prev history ;; elements in the comint successively, and search the string @@ -1491,7 +1492,7 @@ (defun comint-history-isearch-search () (when (null comint-input-ring-index) (error "End of history; no next item")) (comint-next-input 1) - (goto-char (comint-line-beginning-position))) + (goto-char (field-beginning))) (t ;; Signal an error here explicitly, because ;; `comint-previous-input' doesn't signal an error. @@ -1509,7 +1510,7 @@ (defun comint-history-isearch-search () (unless isearch-forward ;; For backward search, don't search ;; in the comint prompt - (comint-line-beginning-position)) + (field-beginning)) noerror))) ;; Return point of the new search result (point))