GNU bug report logs - #33230
26.1; Soft-wrap issue in term.el with term-suppress-hard-newline

Previous Next

Package: emacs;

Reported by: Bruno CHARRON <bruno <at> charron.email>

Date: Thu, 1 Nov 2018 18:31:02 UTC

Severity: normal

Tags: confirmed

Found in versions 26.1, 24.4

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 33230 in the body.
You can then email your comments to 33230 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#33230; Package emacs. (Thu, 01 Nov 2018 18:31:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bruno CHARRON <bruno <at> charron.email>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Thu, 01 Nov 2018 18:31:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bruno CHARRON <bruno <at> charron.email>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.1; Soft-wrap issue in term.el with term-suppress-hard-newline
Date: Fri, 2 Nov 2018 03:11:09 +0900
Running 'emacs -Q', I load the latest 'term.el' in master (commit
bd36ab5), then set term-suppress-hard-newline to 't' and launch 'term'
with zsh as shell.
When typing a command which overflows the screen width, the shell sends
a "soft-wrap" after typing a character on the last column, say 'x
^M^[[K' after typing 'x' but 'term' does not wrap, it continues the same
row.
Then when hitting backspace, the shell asks to go up a row '^[[A' and
the 'term' state becomes inconsistent as it did not go down before.
The reason seems to be that at line 2912 (term.el, commit bd36ab5), 'x '
is inserted which makes the cursor go one column past the edge of the
screen and the wrapping at line 2936 only checks that the cursor is
exactly at the edge of the screen.
When term-suppress-hard-newline is nil, the wrapping is properly done
thanks to the '>' condition at line 2903.

In GNU Emacs 26.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.18.9)
 of 2018-05-29 built on lgw01-amd64-038
Windowing system distributor 'The X.Org Foundation', version 11.0.11804000
System Description: Ubuntu 16.04.5 LTS




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#33230; Package emacs. (Thu, 01 Nov 2018 22:54:01 GMT) Full text and rfc822 format available.

Message #8 received at 33230 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Bruno CHARRON <bruno <at> charron.email>
Cc: 33230 <at> debbugs.gnu.org
Subject: Re: bug#33230: 26.1;
 Soft-wrap issue in term.el with term-suppress-hard-newline
Date: Thu, 01 Nov 2018 18:53:21 -0400
Bruno CHARRON <bruno <at> charron.email> writes:

> Running 'emacs -Q', I load the latest 'term.el' in master (commit
> bd36ab5), then set term-suppress-hard-newline to 't' and launch 'term'
> with zsh as shell.
> When typing a command which overflows the screen width, the shell sends
> a "soft-wrap" after typing a character on the last column, say 'x
> ^M^[[K' after typing 'x' but 'term' does not wrap, it continues the same
> row.

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?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#33230; Package emacs. (Fri, 02 Nov 2018 00:52:02 GMT) Full text and rfc822 format available.

Message #11 received at 33230 <at> debbugs.gnu.org (full text, mbox):

From: Bruno CHARRON <bruno <at> charron.email>
To: npostavs <at> gmail.com
Cc: 33230 <at> debbugs.gnu.org
Subject: Re: bug#33230: 26.1;
 Soft-wrap issue in term.el with term-suppress-hard-newline
Date: Fri, 2 Nov 2018 09:50:57 +0900
On Fri, Nov 2, 2018 at 7:53 AM Noam Postavsky <npostavs <at> gmail.com> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#33230; Package emacs. (Sat, 03 Nov 2018 02:16:01 GMT) Full text and rfc822 format available.

Message #14 received at 33230 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Bruno CHARRON <bruno <at> charron.email>
Cc: 33230 <at> debbugs.gnu.org
Subject: Re: bug#33230: 26.1;
 Soft-wrap issue in term.el with term-suppress-hard-newline
Date: Fri, 02 Nov 2018 22:15:17 -0400
found 33230 24.4
tags 33230 + confirmed
quit

Bruno CHARRON <bruno <at> charron.email> 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?




bug Marked as found in versions 24.4. Request was from Noam Postavsky <npostavs <at> gmail.com> to control <at> debbugs.gnu.org. (Sat, 03 Nov 2018 02:16:02 GMT) Full text and rfc822 format available.

Added tag(s) confirmed. Request was from Noam Postavsky <npostavs <at> gmail.com> to control <at> debbugs.gnu.org. (Sat, 03 Nov 2018 02:16:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#33230; Package emacs. (Sun, 04 Nov 2018 07:24:01 GMT) Full text and rfc822 format available.

Message #21 received at 33230 <at> debbugs.gnu.org (full text, mbox):

From: Bruno CHARRON <bruno <at> charron.email>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 33230 <at> debbugs.gnu.org
Subject: Re: bug#33230: 26.1;
 Soft-wrap issue in term.el with term-suppress-hard-newline
Date: Sun, 4 Nov 2018 16:23:25 +0900
> 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 <at> gnu.org:
bug#33230; Package emacs. (Sun, 04 Nov 2018 09:08:02 GMT) Full text and rfc822 format available.

Message #24 received at 33230 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Bruno CHARRON <bruno <at> charron.email>, Noam Postavsky <npostavs <at> gmail.com>
Cc: 33230 <at> debbugs.gnu.org
Subject: Re: bug#33230: 26.1;
 Soft-wrap issue in term.el with term-suppress-hard-newline
Date: Sun, 04 Nov 2018 10:07:25 +0100
> 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.

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.

martin




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#33230; Package emacs. (Sun, 04 Nov 2018 09:57:03 GMT) Full text and rfc822 format available.

Message #27 received at 33230 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Bruno CHARRON <bruno <at> charron.email>, Noam Postavsky <npostavs <at> gmail.com>
Cc: 33230 <at> debbugs.gnu.org
Subject: Re: bug#33230: 26.1;
 Soft-wrap issue in term.el with term-suppress-hard-newline
Date: Sun, 04 Nov 2018 10:56:20 +0100
[Message part 1 (text/plain, inline)]
> 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.

Attached find a patch for this against the release branch.  Please try
it.

Thanks, martin
[run-window-configuration-change.diff (text/plain, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#33230; Package emacs. (Sun, 04 Nov 2018 11:07:01 GMT) Full text and rfc822 format available.

Message #30 received at 33230 <at> debbugs.gnu.org (full text, mbox):

From: Bruno CHARRON <bruno <at> charron.email>
To: rudalics <at> gmx.at
Cc: 33230 <at> debbugs.gnu.org, Noam Postavsky <npostavs <at> gmail.com>
Subject: Re: bug#33230: 26.1;
 Soft-wrap issue in term.el with term-suppress-hard-newline
Date: Sun, 4 Nov 2018 20:06:25 +0900
>  > 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.
>
> Attached find a patch for this against the release branch.  Please try
> it.

Thanks martin, I confirm that after applying your patch on the 26.1
release, COLUMNS is correctly updated in the shell at each frame
resize while it is not without the patch.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#33230; Package emacs. (Tue, 13 Nov 2018 09:09:02 GMT) Full text and rfc822 format available.

Message #33 received at 33230 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Bruno CHARRON <bruno <at> charron.email>
Cc: 33230 <at> debbugs.gnu.org, "eliz <at> gnu.org" <eliz <at> gnu.org>,
 Noam Postavsky <npostavs <at> gmail.com>
Subject: Re: bug#33230: 26.1;
 Soft-wrap issue in term.el with term-suppress-hard-newline
Date: Tue, 13 Nov 2018 10:07:53 +0100
>> Attached find a patch for this against the release branch.  Please try
>> it.
>
> Thanks martin, I confirm that after applying your patch on the 26.1
> release, COLUMNS is correctly updated in the shell at each frame
> resize while it is not without the patch.

Eli - is this OK to install on the release branch?  It restores the
behavior of Emacs 25 to fix a bug introduced in 26.1.

martin




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#33230; Package emacs. (Tue, 13 Nov 2018 17:19:01 GMT) Full text and rfc822 format available.

Message #36 received at 33230 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 33230 <at> debbugs.gnu.org, bruno <at> charron.email, npostavs <at> gmail.com
Subject: Re: bug#33230: 26.1;
 Soft-wrap issue in term.el with term-suppress-hard-newline
Date: Tue, 13 Nov 2018 19:18:12 +0200
> Date: Tue, 13 Nov 2018 10:07:53 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: Noam Postavsky <npostavs <at> gmail.com>, 33230 <at> debbugs.gnu.org, 
>  "eliz <at> gnu.org" <eliz <at> gnu.org>
> 
>  >> Attached find a patch for this against the release branch.  Please try
>  >> it.
>  >
>  > Thanks martin, I confirm that after applying your patch on the 26.1
>  > release, COLUMNS is correctly updated in the shell at each frame
>  > resize while it is not without the patch.
> 
> Eli - is this OK to install on the release branch?  It restores the
> behavior of Emacs 25 to fix a bug introduced in 26.1.

I'm too confused about this to be able to make up my mind.  Please
help me figure out what am I missing.

You said up-thread:

> > 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.
> 
> 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.

My confusion about this is twofold: (1) the original report for this
bug doesn't seem to involve any resizing of a frame, 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, and why do
you want to do exactly what the ELisp manual says we don't?

Thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#33230; Package emacs. (Wed, 14 Nov 2018 08:34:03 GMT) Full text and rfc822 format available.

Message #39 received at 33230 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 33230 <at> debbugs.gnu.org, bruno <at> charron.email, npostavs <at> gmail.com
Subject: Re: bug#33230: 26.1;
 Soft-wrap issue in term.el with term-suppress-hard-newline
Date: Wed, 14 Nov 2018 09:32:57 +0100
>> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#33230; Package emacs. (Wed, 14 Nov 2018 15:37:01 GMT) Full text and rfc822 format available.

Message #42 received at 33230 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 33230 <at> debbugs.gnu.org, bruno <at> charron.email, npostavs <at> gmail.com
Subject: Re: bug#33230: 26.1;
 Soft-wrap issue in term.el with term-suppress-hard-newline
Date: Wed, 14 Nov 2018 17:36:40 +0200
> Date: Wed, 14 Nov 2018 09:32:57 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: bruno <at> charron.email, npostavs <at> gmail.com, 33230 <at> debbugs.gnu.org
> 
> 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.

So you propose to fix something not directly related to the current
bug by reverting to pre-Emacs 26 behavior, and also make NEWS and the
manual consistent with the change?  If so, I'm okay with doing that on
the emacs-26 branch.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#33230; Package emacs. (Sun, 18 Nov 2018 09:23:02 GMT) Full text and rfc822 format available.

Message #45 received at 33230 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Bruno CHARRON <bruno <at> charron.email>
Cc: 33230 <at> debbugs.gnu.org, Noam Postavsky <npostavs <at> gmail.com>
Subject: Re: bug#33230: 26.1;
 Soft-wrap issue in term.el with term-suppress-hard-newline
Date: Sun, 18 Nov 2018 10:22:26 +0100
> Thanks martin, I confirm that after applying your patch on the 26.1
> release, COLUMNS is correctly updated in the shell at each frame
> resize while it is not without the patch.

I applied a different fix provided by Gary Fredericks to the release
branch now.  Please test that.

Thanks, martin




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#33230; Package emacs. (Sun, 18 Nov 2018 16:19:02 GMT) Full text and rfc822 format available.

Message #48 received at 33230 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Charron <bruno <at> charron.email>
To: rudalics <at> gmx.at
Cc: 33230 <at> debbugs.gnu.org, Noam Postavsky <npostavs <at> gmail.com>
Subject: Re: bug#33230: 26.1;
 Soft-wrap issue in term.el with term-suppress-hard-newline
Date: Mon, 19 Nov 2018 01:17:40 +0900
> I applied a different fix provided by Gary Fredericks to the release
> branch now.  Please test that.

Thanks martin, I confirm that COLUMNS is correctly updated in the
shell at each frame resize on the release branch while it is not
updated when going back to commit d6542ea for example.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#33230; Package emacs. (Sun, 18 Nov 2018 19:42:01 GMT) Full text and rfc822 format available.

Message #51 received at 33230 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Bruno Charron <bruno <at> charron.email>
Cc: 33230 <at> debbugs.gnu.org, Noam Postavsky <npostavs <at> gmail.com>
Subject: Re: bug#33230: 26.1;
 Soft-wrap issue in term.el with term-suppress-hard-newline
Date: Sun, 18 Nov 2018 20:40:54 +0100
> Thanks martin, I confirm that COLUMNS is correctly updated in the
> shell at each frame resize on the release branch while it is not
> updated when going back to commit d6542ea for example.

Many thanks for the prompt confirmation.

martin




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#33230; Package emacs. (Tue, 22 Mar 2022 15:43:01 GMT) Full text and rfc822 format available.

Message #54 received at 33230 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Bruno Charron <bruno <at> charron.email>
Cc: rudalics <at> gmx.at, 33230 <at> debbugs.gnu.org, Noam Postavsky <npostavs <at> gmail.com>
Subject: Re: bug#33230: 26.1; Soft-wrap issue in term.el with
 term-suppress-hard-newline
Date: Tue, 22 Mar 2022 16:42:45 +0100
Bruno Charron <bruno <at> charron.email> writes:

>> I applied a different fix provided by Gary Fredericks to the release
>> branch now.  Please test that.
>
> Thanks martin, I confirm that COLUMNS is correctly updated in the
> shell at each frame resize on the release branch while it is not
> updated when going back to commit d6542ea for example.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

This bug was then left open, but skimming this bug report, it seems like
the problem was fixed, so I'm closing it now.  If I misunderstood,
please respond to the debbugs address and we'll reopen.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




bug closed, send any further explanations to 33230 <at> debbugs.gnu.org and Bruno CHARRON <bruno <at> charron.email> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Tue, 22 Mar 2022 15:44:01 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Wed, 20 Apr 2022 11:24:09 GMT) Full text and rfc822 format available.

This bug report was last modified 1 year and 343 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.