From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Bob Rogers Newsgroups: gmane.emacs.bugs Subject: bug#61069: 30.0.50; comint-copy-old-input should include continuation lines Date: Wed, 25 Jan 2023 23:33:42 -0800 Message-ID: <25554.11478.609268.317183@orion.rgrjr.com> References: <25553.55974.767552.842578@orion.rgrjr.com> <834jsdg4jh.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="549"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 61069@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jan 26 08:34:15 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pKwlz-000ARr-DP for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 26 Jan 2023 08:34:15 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pKwlp-00037f-80; Thu, 26 Jan 2023 02:34:05 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pKwlm-00037R-T1 for bug-gnu-emacs@gnu.org; Thu, 26 Jan 2023 02:34:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pKwlm-0003XN-IA for bug-gnu-emacs@gnu.org; Thu, 26 Jan 2023 02:34:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pKwlm-0005JE-71 for bug-gnu-emacs@gnu.org; Thu, 26 Jan 2023 02:34:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Bob Rogers Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 26 Jan 2023 07:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61069 X-GNU-PR-Package: emacs Original-Received: via spool by 61069-submit@debbugs.gnu.org id=B61069.167471843320391 (code B ref 61069); Thu, 26 Jan 2023 07:34:02 +0000 Original-Received: (at 61069) by debbugs.gnu.org; 26 Jan 2023 07:33:53 +0000 Original-Received: from localhost ([127.0.0.1]:60500 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pKwld-0005Ip-2j for submit@debbugs.gnu.org; Thu, 26 Jan 2023 02:33:53 -0500 Original-Received: from mail-oa1-f52.google.com ([209.85.160.52]:46770) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pKwla-0005Ic-Hr for 61069@debbugs.gnu.org; Thu, 26 Jan 2023 02:33:52 -0500 Original-Received: by mail-oa1-f52.google.com with SMTP id 586e51a60fabf-15f97c478a8so1395537fac.13 for <61069@debbugs.gnu.org>; Wed, 25 Jan 2023 23:33:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rgrjr-com.20210112.gappssmtp.com; s=20210112; h=references:in-reply-to:subject:cc:to:date:message-id :content-transfer-encoding:mime-version:from:from:to:cc:subject:date :message-id:reply-to; bh=FHz0OEyj1UWrve0Zxi1iOSipjvf3S1XwqHgOHmknmqE=; b=1vYZ0BZFPn32E+aLxnGZ2Vew4kgzjoUQfWPazXSnqEJDGjd1OKod93I+AUKQC7LDHd B0lD/G6bGdsuWROXOg/MKobqwRiYe5aAFgYYTdiN16hOSzknYLeHagbBmYZnaxkBLvWV YDgVGsRz37zg19Nvmr4Clh6qH3DCF3ir067KPQj4iUeJZ2nFMTZyj/qRlaE6tZrlYWxN TKeKNxVmt25zwWXo8uoTHYbFiSV/FVsNq4jF2TTFN1pWbl5WsXLsXw5XWdVsA/vWBhyu ay2ZZpcg9i8qGG1Xf0tnw9EnYyBAA4qA20q+s4gR0S634qw3NzUZoGCL8CQaZtygE/qV ZpYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=references:in-reply-to:subject:cc:to:date:message-id :content-transfer-encoding:mime-version:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=FHz0OEyj1UWrve0Zxi1iOSipjvf3S1XwqHgOHmknmqE=; b=BpE8V1LE4DVD8hvR/Oo7e5ZOH8ozaLBKHWHKSZ5ov9yYzmogwLprxXcWwGFSYh8NHm d+lZYQ/WmAn8/IRn9o28u/VN5S/bR/0MPoCr/B8ewELLIFS8MJzy2yDseI1BNmqek80a F6j3J6u8obeTxOgd+EoCasSpOVbwcxRl21qZa69jpQCrtot10UIoB1ZY+70MX74niBT5 gvCyuUMtgsJIQVDXB2aBRxQDPsW8kqeuLBUg5BX6Pxb+KYdlAyVIhNlhZUeI3Z9gc/gI N3H5CG2UrMOZKRWpOTsgwCSJnPaW2hpD0ga7gypwEmCBMXpebfngWmNL1Kh7mXnjH4Dk kxAw== X-Gm-Message-State: AFqh2kqBAm2ByMqWaXEgZMV5vU/uveokw8jQXbST7F0kS+22jAp21Qzd fb81rT6uIb9yc6sl8sf/iAo4XovOkf1w0V3q X-Google-Smtp-Source: AMrXdXsNVgcJf5ZRYmkMuuxIAvmaMf8P9uXkbRLQ0BfaLmOn/jDC4lpCR2P1gUOEoKEzW9vadBIGdA== X-Received: by 2002:a05:6870:17a8:b0:15f:dbf0:20e8 with SMTP id r40-20020a05687017a800b0015fdbf020e8mr11197621oae.43.1674718424851; Wed, 25 Jan 2023 23:33:44 -0800 (PST) Original-Received: from orion.rgrjr.com ([2600:1700:7c2c:e000::24]) by smtp.gmail.com with ESMTPSA id n16-20020a9d7110000000b00670523bf1cfsm181151otj.47.2023.01.25.23.33.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Jan 2023 23:33:44 -0800 (PST) In-Reply-To: <834jsdg4jh.fsf@gnu.org> X-Mailer: VM 8.2.0b under 30.0.50 (x86_64-pc-linux-gnu) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:254179 Archived-At: From: Eli Zaretskii Date: Thu, 26 Jan 2023 09:04:34 +0200 > From: Bob Rogers > Date: Wed, 25 Jan 2023 17:43:02 -0800 > > In a shell-mode buffer with lots of "make" output, there will often > appear commands with continuation lines. To use them as new input > (e.g. while debugging some bit of makefile logic) requires either > marking and copying multiple lines, or multiple invocations of > comint-copy-old-input (C-RET in shell-mode) to get the complete command. > The attached patch against f0971f94fe42224b4d85bb8b6188d5d805689ddf in > master includes those continuation lines, which seems like a desirable > bit of dwimmery. However, I may have misunderstood the purpose of the > line-end-position vs. field-end thing. Also, this assumes shell syntax, > so it may be more appropriate to leave comint-get-old-input-default > alone and give shell-mode its own shell-get-old-input-default function. I don't understand: line-end-position already reports the entire line, including continuation lines. So could you explain the problem with the current code in more detail, please? I'm speaking of shell continuation lines, where a command is broken across multiple physical lines with backslashes. Perhaps you think I am referring to display line wrapping; is where we are miscommunicating? > + ;; Include continuation lines as long as the current > + ;; line ends with a backslash. > + (while (and (not (eobp)) > + (= (char-before) ?\\)) > + (goto-char (line-end-position 2)))) Or maybe I don't understand what is this "backslash" business is about? AFAICT, the "backslashes" shown for long lines of Make output are those produced by the Emacs display, not by the shell, so the code you want to change should already take care of that. What am I missing? Could you please show an example of "long Make output" where the current code doesn't DTRT, so we'd be on the same page wrt the problem? Thanks. Here's an example from building emacs: . . . rm -f emacs && cp -f temacs emacs LC_ALL=C ./temacs -batch -l loadup --temacs=pdump \ --bin-dest /usr/local/bin/ --eln-dest /usr/local/lib64/emacs/30.0.50/ Loading loadup.el (source)... Dump mode: pdump . . . My thought is that C-RET on the "./temacs -batch" line in a *shell* buffer should take both that line and the next. -- Bob