[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: martin rudalics
Subject: 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.


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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]