Yep, it seems to work with the patch applied.

Gary Fredericks
(803)-295-0195
fredericksgary@gmail.com
gfredericks.com


On Sun, Nov 4, 2018 at 3:56 AM martin rudalics <rudalics@gmx.at> wrote:

>  > *Affects*: version 26 (git-bisected to commit 8e7712c7afc)
>  >
>  > Note: I have only tried this on --without-x emacs
>  >
>  > *Steps to reproduce*
>  >
>  >     1. start emacs
>  >     2. start a term buffer with M-x term
>  >     3. run `seq 1000` at the bash prompt to fill the screen
>  >     4. enlarge the terminal window that emacs is running in, so that the
>  >     window size changes as well
>  >     5. run `seq 1000` again, and observe that the new space at the
> bottom of
>  >     the buffer is not being used
>  >
>  > *Analysis notes*
>  >
>  > term-mode *does* pick up changes after more explicit window
> configurations,
>  > like splits; my workaround for months has been to split and join the
>  > terminal window whenever I've resized it.
>  >
>  > As best I can tell, term-mode subscribes to window size changes by
> adding
>  > advice to the window-adjust-process-window-size-function variable, and
> the
>  > 8e7712c7afc reduced the set of situations in which that function is
> called.
>  >
>  > I've developed a more automated workaround with a term-load-hook of this
>  > form:
>  >
>  > (add-hook 'window-size-change-functions (lambda (_frame)
>  > (window--adjust-process-windows)))
>  >
>  > It might be that adding this line to the term-mode setup steps would be
>  > sufficient, but I'm not familiar enough with the window.el code to have
> a
>  > guess whether that's actually a good approach.
>
> While all you write above is correct and I agree with the fix you
> propose, I tend to restore the old behavior as with the attached
> patch.  The reason is that I have no idea in how many more yet
> unrevealed occasions my commit had adverse effects so I'd rather be on
> the safe side for Emacs 26.2.  Please try the patch and tell me
> whether it indeed restores the old behavior.
>
> Thanks, martin
>