From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Bruno CHARRON Newsgroups: gmane.emacs.bugs Subject: bug#33230: 26.1; Soft-wrap issue in term.el with term-suppress-hard-newline Date: Sun, 4 Nov 2018 16:23:25 +0900 Message-ID: References: <87h8h0if4u.fsf@gmail.com> <87bm76j496.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1541316129 13727 195.159.176.226 (4 Nov 2018 07:22:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 4 Nov 2018 07:22:09 +0000 (UTC) Cc: 33230@debbugs.gnu.org To: Noam Postavsky Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Nov 04 08:22:05 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gJCjT-0003QZ-GP for geb-bug-gnu-emacs@m.gmane.org; Sun, 04 Nov 2018 08:22:03 +0100 Original-Received: from localhost ([::1]:57882 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gJClZ-0000T4-St for geb-bug-gnu-emacs@m.gmane.org; Sun, 04 Nov 2018 02:24:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51416) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gJClR-0000Sw-G6 for bug-gnu-emacs@gnu.org; Sun, 04 Nov 2018 02:24:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gJClO-0004zL-Bl for bug-gnu-emacs@gnu.org; Sun, 04 Nov 2018 02:24:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:57273) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gJClO-0004zE-0b for bug-gnu-emacs@gnu.org; Sun, 04 Nov 2018 02:24:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gJClN-0007tM-Sj for bug-gnu-emacs@gnu.org; Sun, 04 Nov 2018 02:24:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Bruno CHARRON Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 04 Nov 2018 07:24:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33230 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed Original-Received: via spool by 33230-submit@debbugs.gnu.org id=B33230.154131623830326 (code B ref 33230); Sun, 04 Nov 2018 07:24:01 +0000 Original-Received: (at 33230) by debbugs.gnu.org; 4 Nov 2018 07:23:58 +0000 Original-Received: from localhost ([127.0.0.1]:33298 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gJClJ-0007t4-KC for submit@debbugs.gnu.org; Sun, 04 Nov 2018 02:23:57 -0500 Original-Received: from mx1.polytechnique.org ([129.104.30.34]:56999) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gJClG-0007sv-Us for 33230@debbugs.gnu.org; Sun, 04 Nov 2018 02:23:55 -0500 Original-Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id 2EABF564762 for <33230@debbugs.gnu.org>; Sun, 4 Nov 2018 08:23:50 +0100 (CET) Original-Received: by mail-wr1-f51.google.com with SMTP id j17-v6so875378wrq.11 for <33230@debbugs.gnu.org>; Sun, 04 Nov 2018 00:23:50 -0700 (PDT) X-Gm-Message-State: AGRZ1gIdAdMjEeU/38gTK6UJ4MAK9plUdG8Lo3IyjXWsiooq4gy3Ul3L lENL4fk7KPC60G8OYwnP6lgRkBscy7Rv55h/8TE= X-Google-Smtp-Source: AJdET5dXKOx0P7IOzh8C2h5ZF9SZ9pAM/dGZXvdnnJ8+vjmfncpqKt2mapOtwlK4kSVA1dczAg0D9KBWC8rNYPCO2qg= X-Received: by 2002:a5d:45c3:: with SMTP id b3-v6mr15048660wrs.296.1541316230380; Sun, 04 Nov 2018 00:23:50 -0700 (PDT) In-Reply-To: <87bm76j496.fsf@gmail.com> X-Gmail-Original-Message-ID: X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Sun Nov 4 08:23:51 2018 +0100 (CET)) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:151999 Archived-At: > It seems like this option is somewhat incompatible with shells, it's not > clear what the right behaviour would be. You say the problem is that > there is no wrapping, but isn't term-suppress-hard-newline exactly > intended to suppress this kind of wrapping? The option is said to "mean[s] text can automatically reflow if the window is resized" and I think the behavior of libvte with the rewrap option implements that well. You can see in [1] the behavior with and without the option in gnome-terminal 3.18.3. The option is extensively documented here [3]. For emacs, the rewrapping is currently done well with term-suppress-hard-newline for all lines except the command currently edited. One solution, though non-trivial, may be to interpret the cursor movements (from the shell) which fall within the "region" of the last (emacs) line, corresponding to several (shell) lines if there was wrapping, as movements within the last (emacs) line. Emacs moves to a new line only if the shell movements take it away from the current "region". For example, with width 20, after typing x repeatedly, _ is the cursor on the last column (emacs current col: 19) $ xxxxxxxxxxxxxxxxx_ Here, the last emacs line corresponds to a "region" of one (shell) line. Then typing x, the shell (bash) sends "x ^M" and thinks the display is $ xxxxxxxxxxxxxxxxxx _ but emacs still displays a single line, visually wrapped or truncated according to emacs' config $ xxxxxxxxxxxxxxxxxxx_ to get there, it first processes "x ", the cursor is now at column 21, then it processes ^M and since the width is 20, it moves the cursor to the beginning of the current (shell) line which is at column 21 - (21 % 20) = 20. Here, the last emacs line corresponds to a "region" of two (shell) lines. Then after hitting backspace, the shell sends "^[[A^[[19C^[[K^M^J^M^[[K^[[A^[[19C" and thinks the display is $ xxxxxxxxxxxxxxxxx_ (with an empty line) and emacs shows $ xxxxxxxxxxxxxxxxx_ to get there, it virtually moves up one line (but actually goes 20 columns left due to width = 20 so current col: 20 - 20 = 0) due to ^[[A, then 19 columns right (current col: 0 + 19 = 19) due to ^[[19C then erases up to the end of the virtual line (before col (19 + 20) - ((19 + 20) % 20) = 20) due to ^[[K, then moves back to the beginning of the virtual line (current col: 19 - (19 % 20) = 0) due to ^M, moves down one virtual line (current col: 0 + 20 = 20) due to ^K, erases up to the end of the virtual line (before col (20 + 20) - ((20 + 20) % 20) = 40) due to ^[[K, moves up one virtual line (current col 20 - 20 = 0) due to ^[[A, then 19 columns right (current col: 0 + 19 = 19). Here, the last emacs line corresponds to a "region" of only one (shell) lines, as the second (shell) line is empty (due to ^M^[[K) and does not contain the cursor, so that if we execute and the shell sends a newline ^J to print the output, the output will fall within a new (emacs) line. Definitely non-trivial but I don't have another solution in mind that would give the expected behavior. I don't know how Visual Line works but it seems the idea is similar so maybe it can be reused? Instead of remapping the user's cursor movement to movements on the visual lines, we would like to remap the shell's cursor movement to movements on the visual lines instead of the logical lines. Another issue I found that may need to be addressed to get a behavior similar to gnome-terminal above is that the shell is not aware (checking $COLUMS) of when the frame is resized, only when its window is resized and there is another window on the side. [1] https://imgur.com/a/7IwZfmy [2] https://gitlab.gnome.org/GNOME/vte/blob/master/doc/rewrap.txt