GNU bug report logs - #32720
term-mode ignores certain window size changes

Previous Next

Full log

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

From: Gary Fredericks <fredericksgary <at> gmail.com>
To: rudalics <at> gmx.at
Cc: 32720 <at> debbugs.gnu.org
Subject: Re: bug#32720: term-mode ignores certain window size changes
Date: Fri, 16 Nov 2018 06:15:56 -0600

[Message part 1 (text/plain, inline)]

Yep, it seems to work with the patch applied.

Gary Fredericks
(803)-295-0195
fredericksgary <at> gmail.com
gfredericks.com


On Sun, Nov 4, 2018 at 3:56 AM martin rudalics <rudalics <at> 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
>

[Message part 2 (text/html, inline)]

Previous Next

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