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

Previous Next

Full log

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.

Previous Next

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