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

[Eli Zaretskii]

> Date: Wed, 14 Nov 2018 09:32:57 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: bruno@charron.email, npostavs@gmail.com, 33230@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.