Message received at 33230 <at> debbugs.gnu.org:

Received: (at 33230) by debbugs.gnu.org; 14 Nov 2018 08:33:26 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Nov 14 03:33:25 2018
Received: from localhost ([127.0.0.1]:50917 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1gMqc1-00012I-LC
for submit <at> debbugs.gnu.org; Wed, 14 Nov 2018 03:33:25 -0500
Received: from mout.gmx.net ([212.227.15.19]:41799)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <rudalics@HIDDEN>) id 1gMqbv-00011y-Ah
for 33230 <at> debbugs.gnu.org; Wed, 14 Nov 2018 03:33:20 -0500
Received: from [192.168.1.101] ([212.95.5.83]) by mail.gmx.com (mrgmx003
[212.227.17.190]) with ESMTPSA (Nemesis) id 0MUZKF-1fvah131Up-00RG4l; Wed, 14
Nov 2018 09:33:04 +0100
Message-ID: <5BEBDDB9.20401@HIDDEN>
Date: Wed, 14 Nov 2018 09:32:57 +0100
From: martin rudalics <rudalics@HIDDEN>
MIME-Version: 1.0
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#33230: 26.1;
Soft-wrap issue in term.el with term-suppress-hard-newline
References: <CAKx9rsxSXH+RWrDjUcgiH0fTDdEPdCm8E+7hwhWgpzirO=eQew@HIDDEN>
<87h8h0if4u.fsf@HIDDEN>
<CAKx9rszXVvO-in25dN=+Pe9HFAc7T37W7x_jd6gTnf0w5hi-5Q@HIDDEN>
<87bm76j496.fsf@HIDDEN>
<CAKx9rsz15SP4PHJt67jMAQMegaEvP0SFCDvtU_jycSqZUH1DBQ@HIDDEN>
<5BDEB6CD.2050407@HIDDEN> <5BDEC244.3040002@HIDDEN>
<CAKx9rsz5cPuOKA9Ce6rcOFaw4WgVoKhhkXbxe98r+fWtOKu9og@HIDDEN>
<5BEA9469.7080502@HIDDEN> <83muqc99rf.fsf@HIDDEN>
In-Reply-To: <83muqc99rf.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:I1ka981aLZv49Sz3+fpe1fGw+7KzCavH+rHfSdb1ehDakf5gYYo
b6PPRbZ8ACH+0zsWg+RRhofiJwFRmi4vFPT9NsVQot/h6Qai6vAnJDL5OjMbiKRPE+NI2c/
+XUq7qnpUtzeJqXscsRf+17kGxWKFKOs7b43SNiI/fFlFV3pLneAIZL9uJR23ijke/e4QSS
IbaE1L7XgTNAF0hilEoyg==
X-Spam-Flag: NO
X-UI-Out-Filterresults: notjunk:1;V01:K0:nM46f8bVk0o=:v/rknfHF1u6bnu8Gr5EAJd
UXUaJJNVrkMsOiE9mGid7iQMUDzFFT/KNeKHzS7elOG2w+0a+LiGBgJy5xwCmnKJw/bK8NZIm
6rybDzhV1ePChCBIgr7On3jJROltr76AUFsBxOGQ3eZuCErUoreuNMnrPXfRxTyjrQ/+zLiq4
wT1COnV4XnVYUVbdRCOACPMzaBja4DoU7NCLsAcpiGaEc3Cvk9YPcSWgu/xvSYMa3tg/RU8jc
AcXC9ndlNMCNSbWpp+Xf/2uwrgy/sfUXZKrDoSU8Xnnjnoa/uEGrVF7tEQfRW4V4Eg1gTUIOp
dWcvLI+phVy+/bxsByZuwISi+dWqnWFMm+Rd+UqGnhlQjNVqyfs7oaBEvV9PifkF5AjAIqyck
8Tx2a93C7C2UPRqQ7xwU71C/9K7/1BNYcaT3hUYMwSpqyiMIsczDimPlASrF4w0ggCZee/8yr
QX9CM4dPcq2d4MVKCp5kwWeCdzYjzTCX12014ygN4cFOyOXllwPFW9hGHjgKex+CDhsNa2BVv
pnejU9vA2gj5q6XrnZx7F8kSIbEkutb2QocaePUuYBb+Nj/yMKlHFv5wVDU50+HkJKGFpN3qQ
5Uar9ox1jyjRf7BL8hNtrZ5zwg1/LimOtwGKYBDwa01ROH3UqfYXQOx6KGrX2ZNCqCJNhZZdb
mP7KBykkBq175+FtAWbrHBFTHxDBwY0BKBLR9IcqFjhiK8zcB0uHm/sgTFwNDUtmNxEGaICby
ZTFJUjH4rTopvamfA0chhMEd51eKpiT9b++ic7kAkPeS+9MczNGgejPkfmbSV32zc5E1LNIov
bIjKb9pIemr2wuLEGPQq0Oq0ZE09jiY8enB2/QBxiP8j3QXTxrpN/bNuImvTgjh4O1gYJhSYg
r/vymd4lqZ1EiFtVw2k/2+FtWJprp2Xkk6Eky3U/SpBiQTZou3n/TW78Z4LaKn
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 33230
Cc: 33230 <at> debbugs.gnu.org, bruno@HIDDEN, npostavs@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)
>> FWIW this is Bug#32720 for which I am responsible. It will be fixed
>> in Emacs 26.2 by reestablishing the behavior of Emacs 25.
>
> And your proposed change runs window-configuration-change-hook in two
> additional places.
Right.
> My confusion about this is twofold: (1) the original report for this
> bug doesn't seem to involve any resizing of a frame,
At the end it says:
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.
> and (2) the ELisp
> manual explicitly says that "resizing the frame or individual windows
> do not count as configuration changes", and thus this hook shouldn't
> be run when the frame is resized.
>
> So how does the proposed change fix the problem at hand,
By running 'window-configuration-change-hook' for frame resizes as
with Emacs 25.
> and why do
> you want to do exactly what the ELisp manual says we don't?
The Elisp manual doesn't represent the facts because we still run the
hook when resizing single windows. The idea behind that text was to
avoid that new code runs 'window-configuration-change-hook' to trace
window size changes because that is unreliable (not all size changes
are caught) and costly (it's often run when no sizes changed at all).
Also NEWS warned that
*** Resizing a frame no longer runs 'window-configuration-change-hook'.
'window-size-change-functions' should be used instead.
and I checked known clients of 'window-configuration-change-hook'
whether they should call 'window-size-change-functions' instead.
Little did I expect to find such a client in window.el though, so this
went unnoticed.
We could add a call to 'window-size-change-functions' as Gary proposed
in the report of Bug#32720. But then 'window--adjust-process-windows'
would be run by both 'window-configuration-change-hook' and
'window-size-change-functions' effectively increasing the number of
calls of that function instead of decreasing it. If you prefer that
solution we can certainly do it.
martin

Message received at 33230 <at> debbugs.gnu.org:

Received: (at 33230) by debbugs.gnu.org; 4 Nov 2018 07:23:58 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Nov 04 02:23:57 2018
Received: from localhost ([127.0.0.1]:33298 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1gJClJ-0007t4-KC
for submit <at> debbugs.gnu.org; Sun, 04 Nov 2018 02:23:57 -0500
Received: from mx1.polytechnique.org ([129.104.30.34]:56999)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <SRS0=NSiq=NP=charron.email=bruno@HIDDEN>)
id 1gJClG-0007sv-Us
for 33230 <at> debbugs.gnu.org; Sun, 04 Nov 2018 02:23:55 -0500
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 <at> debbugs.gnu.org>; Sun, 4 Nov 2018 08:23:50 +0100 (CET)
Received: by mail-wr1-f51.google.com with SMTP id j17-v6so875378wrq.11
for <33230 <at> 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)
MIME-Version: 1.0
References: <CAKx9rsxSXH+RWrDjUcgiH0fTDdEPdCm8E+7hwhWgpzirO=eQew@HIDDEN>
<87h8h0if4u.fsf@HIDDEN>
<CAKx9rszXVvO-in25dN=+Pe9HFAc7T37W7x_jd6gTnf0w5hi-5Q@HIDDEN>
<87bm76j496.fsf@HIDDEN>
In-Reply-To: <87bm76j496.fsf@HIDDEN>
From: Bruno CHARRON <bruno@HIDDEN>
Date: Sun, 4 Nov 2018 16:23:25 +0900
X-Gmail-Original-Message-ID: <CAKx9rsz15SP4PHJt67jMAQMegaEvP0SFCDvtU_jycSqZUH1DBQ@HIDDEN>
Message-ID: <CAKx9rsz15SP4PHJt67jMAQMegaEvP0SFCDvtU_jycSqZUH1DBQ@HIDDEN>
Subject: Re: bug#33230: 26.1;
Soft-wrap issue in term.el with term-suppress-hard-newline
To: Noam Postavsky <npostavs@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Sun Nov 4
08:23:51 2018 +0100 (CET))
X-Spam-Flag: No, tests=bogofilter, spamicity=0.007840, queueID=602085647A5
X-Spam-Score: -2.1 (--)
X-Debbugs-Envelope-To: 33230
Cc: 33230 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.1 (---)
> 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

Information forwarded
to bug-gnu-emacs@HIDDEN:bug#33230; Package emacs.
Full text available.Added tag(s) confirmed.
Request was from Noam Postavsky <npostavs@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.bug Marked as found in versions 24.4.
Request was from Noam Postavsky <npostavs@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.

Message received at 33230 <at> debbugs.gnu.org:

Received: (at 33230) by debbugs.gnu.org; 3 Nov 2018 02:15:29 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 02 22:15:29 2018
Received: from localhost ([127.0.0.1]:60516 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1gIlTE-0004Ir-NR
for submit <at> debbugs.gnu.org; Fri, 02 Nov 2018 22:15:28 -0400
Received: from mail-io1-f44.google.com ([209.85.166.44]:45541)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <npostavs@HIDDEN>)
id 1gIlTC-0004IW-4j; Fri, 02 Nov 2018 22:15:26 -0400
Received: by mail-io1-f44.google.com with SMTP id p83-v6so2680684iod.12;
Fri, 02 Nov 2018 19:15:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:to:cc:subject:references:date:in-reply-to:message-id
:user-agent:mime-version;
bh=oVVyfnBTBqxSDEwJR/PAmnJtMALSSgM30586qE+wcXk=;
b=QrzcjKU4XofwDbK7dVtr0/T1khJ/A7xAHr/3krkva3dx0kl9DauLcUMJ500FfrLCf5
UzLKwQE4OXTnrwl5fD9Tp9kG0TcrMiCqGfk+SqZlwk3n6s8VTFOYS+qC5jNECdbjjds7
tq1cKLKNSqnAUNZzF/ntftL75FsRbP+xy0p8ed6WK/Xmr9dXvDGBpCENpu5NXRuiIjfx
1NIlwRrMjcwAJuhMGoGeeZKfc6Fe0cMBfG2tT98scV0OrTGASFqJg6WJS32jJGDUQPRq
tGfwr9EVmJ7K4YW2MlOly4OKbq4nZARNzYZxRV9TJ/XrLhMFGfESOSTfUx74QSRL0DZm
ZQ2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
:message-id:user-agent:mime-version;
bh=oVVyfnBTBqxSDEwJR/PAmnJtMALSSgM30586qE+wcXk=;
b=fe4X3hf6DPcWGWLCbrESnos3QtbLFpfu/G6OGfnMD4xdQ2CHsYdFdQEAE+bryx+8pw
Pyf0Btq08M0gMMZjp4BRnX9nSFQqCUvKmVwENzspPc2u6dWt5aefbwn5TBPT4Vue4sj6
2wdy7JjXYwo5IPLg77FVTTUq63ucot8/s7RNXgZaESozOWIYzcbQIbgnEE29DXvsZ4qS
vK+XP+kgP+pBIBU2ULAsUjZ0lnSHhh67enVO/RKMUhCD9vahTvEB79LQZPBYD8bh4zCC
BcTDeEhelTyfmaG5Pq0BIK5yLUoNijNpTDD/uWSrJRJBbRtA6b+febyvPQ5JuMbeyxRf
0JBg==
X-Gm-Message-State: AGRZ1gIV/cTXKyaqUq7QLo+dj24YZ+Xbb1CP91kTqdwbR8Sv5rPUVHdB
zO2l5eWUnqU1/o2EyeVV4pjjQZ74
X-Google-Smtp-Source: AJdET5cwQjZSwO+8LQQKN9s0cotnXBkRrtA7X8zQFVDBmFhlX49MixJUtX+SGxvsDXt/Qt4c7ENcbg==
X-Received: by 2002:a6b:f40e:: with SMTP id
i14-v6mr2517899iog.278.1541211320481;
Fri, 02 Nov 2018 19:15:20 -0700 (PDT)
Received: from zebian (cbl-45-2-119-34.yyz.frontiernetworks.ca. [45.2.119.34])
by smtp.googlemail.com with ESMTPSA id
q205-v6sm1341701itc.2.2018.11.02.19.15.18
(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
Fri, 02 Nov 2018 19:15:18 -0700 (PDT)
From: Noam Postavsky <npostavs@HIDDEN>
To: Bruno CHARRON <bruno@HIDDEN>
Subject: Re: bug#33230: 26.1;
Soft-wrap issue in term.el with term-suppress-hard-newline
References: <CAKx9rsxSXH+RWrDjUcgiH0fTDdEPdCm8E+7hwhWgpzirO=eQew@HIDDEN>
<87h8h0if4u.fsf@HIDDEN>
<CAKx9rszXVvO-in25dN=+Pe9HFAc7T37W7x_jd6gTnf0w5hi-5Q@HIDDEN>
Date: Fri, 02 Nov 2018 22:15:17 -0400
In-Reply-To: <CAKx9rszXVvO-in25dN=+Pe9HFAc7T37W7x_jd6gTnf0w5hi-5Q@HIDDEN>
(Bruno CHARRON's message of "Fri, 2 Nov 2018 09:50:57 +0900")
Message-ID: <87bm76j496.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 33230
Cc: 33230 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
found 33230 24.4
tags 33230 + confirmed
quit
Bruno CHARRON <bruno@HIDDEN> writes:
> Basically I am typing 'x' repeatedly in the command line until it reaches the
> right screen edge.
> Setting term-log-buffer as t, I can see what the shell is sending to emacs in
> the Messages buffer.
> When I type 'x' in the middle of the screen, the shell responds 'x' to print an
> 'x' at the current cursor position.
> When I type 'x' on the last column, the shell responds 'x ^M^[[K', which I could
> understand with this explanation [1].
> It seems to be the standard way to ask the terminal to wrap the line under
> uncertainty on its behavior.
> First it asks to insert 'x' on the last column, then some terminals will wrap
> then but just in case it asks to insert an additional ' ' to force wrapping then
> erases the new line (carriage return '^M' then erase to end of line '^[[K', see
> [2]).
> If term.el processes 'x' first then ' ', it will wrap when processing the ' '
> but when term-suppress-hard-newline is t, it processes both at the same time and
> doesn't wrap due to the reason explained in the original post.
Ah, got it. I got mixed up a few times, because I didn't realize it
only happens after the first line (otherwise there's nowhere to go back
up to). I can reproduce this also with 24.4 (when
term-suppress-hard-newline was introduced).
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?

Message received at 33230 <at> debbugs.gnu.org:

Received: (at 33230) by debbugs.gnu.org; 2 Nov 2018 00:51:31 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Nov 01 20:51:31 2018
Received: from localhost ([127.0.0.1]:59083 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1gINgQ-00039Q-MX
for submit <at> debbugs.gnu.org; Thu, 01 Nov 2018 20:51:30 -0400
Received: from mx1.polytechnique.org ([129.104.30.34]:35961)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <SRS0=YjH3=NN=charron.email=bruno@HIDDEN>)
id 1gINgO-00039H-Sl
for 33230 <at> debbugs.gnu.org; Thu, 01 Nov 2018 20:51:29 -0400
Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com
[209.85.221.53])
(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 A26AF56123C
for <33230 <at> debbugs.gnu.org>; Fri, 2 Nov 2018 01:51:25 +0100 (CET)
Received: by mail-wr1-f53.google.com with SMTP id d10-v6so293942wrs.5
for <33230 <at> debbugs.gnu.org>; Thu, 01 Nov 2018 17:51:25 -0700 (PDT)
X-Gm-Message-State: AGRZ1gJviq+XxZXgtejkwCsPfwHRDXxYBJkzTn8/1sc3/2aagKSPbLLD
8R0IPHCE5AFg6CcTxqhQJu0e3ykBlTlTTsXJj/k=
X-Google-Smtp-Source: AJdET5cIbIqn7XHgW6nHFjam7k15xnOGl+IxHi8lHQwv5dM28D/cvwN/zsyy5s8ogrY8dSjAr9q7l6bzZkHNB8M3qjM=
X-Received: by 2002:a5d:6309:: with SMTP id
i9-v6mr8046070wru.163.1541119885119;
Thu, 01 Nov 2018 17:51:25 -0700 (PDT)
MIME-Version: 1.0
References: <CAKx9rsxSXH+RWrDjUcgiH0fTDdEPdCm8E+7hwhWgpzirO=eQew@HIDDEN>
<87h8h0if4u.fsf@HIDDEN>
In-Reply-To: <87h8h0if4u.fsf@HIDDEN>
From: Bruno CHARRON <bruno@HIDDEN>
Date: Fri, 2 Nov 2018 09:50:57 +0900
X-Gmail-Original-Message-ID: <CAKx9rszXVvO-in25dN=+Pe9HFAc7T37W7x_jd6gTnf0w5hi-5Q@HIDDEN>
Message-ID: <CAKx9rszXVvO-in25dN=+Pe9HFAc7T37W7x_jd6gTnf0w5hi-5Q@HIDDEN>
Subject: Re: bug#33230: 26.1;
Soft-wrap issue in term.el with term-suppress-hard-newline
To: npostavs@HIDDEN
Content-Type: text/plain; charset="UTF-8"
X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Fri Nov 2
01:51:25 2018 +0100 (CET))
X-Spam-Flag: No, tests=bogofilter, spamicity=0.100822, queueID=E240656123D
X-Spam-Score: -2.1 (--)
X-Debbugs-Envelope-To: 33230
Cc: 33230 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.1 (---)
On Fri, Nov 2, 2018 at 7:53 AM Noam Postavsky <npostavs@HIDDEN> wrote:
> Can you explain exactly what you're typing in? I don't understand what
> 'x^M^[[K' means here. Is specific to zsh? Is it specific to your
> prompt settings?
Sorry the line break ate the space, the shell response is 'x ^M^[[K' and the
issue is with the space.
Basically I am typing 'x' repeatedly in the command line until it reaches the
right screen edge.
Setting term-log-buffer as t, I can see what the shell is sending to emacs in
the Messages buffer.
When I type 'x' in the middle of the screen, the shell responds 'x' to print an
'x' at the current cursor position.
When I type 'x' on the last column, the shell responds 'x ^M^[[K', which I could
understand with this explanation [1].
It seems to be the standard way to ask the terminal to wrap the line under
uncertainty on its behavior.
First it asks to insert 'x' on the last column, then some terminals will wrap
then but just in case it asks to insert an additional ' ' to force wrapping then
erases the new line (carriage return '^M' then erase to end of line '^[[K', see
[2]).
If term.el processes 'x' first then ' ', it will wrap when processing the ' '
but when term-suppress-hard-newline is t, it processes both at the same time and
doesn't wrap due to the reason explained in the original post.
When the command line has some attributes, e.g. bold red, the shell sends
'^[[1m^[[31mx^[[m^[[39m ^M^[[K', which means turn on bold ('^[[1m') red
('^[[31m'), insert 'x', reset attributes ('^[[m') and set default color
('^[[39m'), insert space, then '^M^[[K' as before.
Interestingly, in that case, term.el will first process the 'x' then the ' '
because there are control commands in between, and there is no issue (it wraps).
See a gif of that behavior in [3].
The behavior is the same with 'bash --norc', although it only returns 'x ^M', no
'^[[K'.
It does not depend on my prompt and also happens with 'zsh -f'.
[1] https://stackoverflow.com/a/31360700
[2] http://man7.org/linux/man-pages/man4/console_codes.4.html
[3] https://i.imgur.com/1dIQ8c6.gif

Acknowledgement sent
to Bruno CHARRON <bruno@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN.
Full text available.Report forwarded
to bug-gnu-emacs@HIDDEN:bug#33230; Package emacs.
Full text available.Please note: This is a static page, with minimal formatting, updated once a day.Click here to see this page with the latest information and nicer formatting.
Last modified:
Sun, 18 Nov 2018 09:30:01 UTC