bug#32720: term-mode ignores certain window size changes

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

bug#32720: term-mode ignores certain window size changes

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

Gary Fredericks
Reply | Threaded
Open this post in threaded view
|

bug#32720: term-mode ignores certain window size changes

martin rudalics
> *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.

Emacs no more runs 'window-configuration-change-hook' when the frame
size changes so your workaround should indeed work around that case.
But you should see a similar problem before commit 8e7712c7afc with a
frame containing a window showing process output and that window's
size gets changed.

In its current form, 'window--adjust-process-windows' is a gross hack.
Putting a function by default on 'window-configuration-change-hook'
(or 'window-size-change-functions') is a bad idea IMO.  There should
be no place for such functions in window.el - a special mode should
take care of them.

martin



Reply | Threaded
Open this post in threaded view
|

bug#32720: term-mode ignores certain window size changes

Eli Zaretskii
> Date: Thu, 13 Sep 2018 10:07:06 +0200
> From: martin rudalics <[hidden email]>
>
> In its current form, 'window--adjust-process-windows' is a gross hack.
> Putting a function by default on 'window-configuration-change-hook'
> (or 'window-size-change-functions') is a bad idea IMO.

Can you elaborate on why do you think these are bad ideas?



Reply | Threaded
Open this post in threaded view
|

bug#32720: term-mode ignores certain window size changes

martin rudalics
 >> In its current form, 'window--adjust-process-windows' is a gross hack.
 >> Putting a function by default on 'window-configuration-change-hook'
 >> (or 'window-size-change-functions') is a bad idea IMO.
 >
 > Can you elaborate on why do you think these are bad ideas?

(1) Preempting a hook is like preempting an option.  And options
should be pristine when starting Emacs.  Users who never run any
processes should not be obliged to remove anything from a hook to
obtain a clean run.  Even if we say that it does not matter much in
the case at hand, this code sets a precedent which others may follow.

(2) I don't know what a "logical" window size is.  Reading the
doc-string of 'window-adjust-process-window-size-function', I
understand that the function this variable is set to should pass the
size of some window showing output of a process to that process.  If
this interpretation is correct, then not hooking into
'window-size-change-functions' will fail to capture explicit resizing
of any such window - usually the most prominent case when a window
size changes.  So what's the aim of 'window--adjust-process-windows'?

In either case, it should not be the task of window.el to find process
windows.  It does not find "Man" or "Info" windows either and calls a
hook in a hook when resizing them although someone might find that
convenient - compare Bug#32536.  Window groups are the most prominent
other example of code that usurpated window.el.  I never understood
why code which pertains to 'follow-mode' was added to window.el.
Adding such code makes the already largest code file in the Lisp
directory more and more difficult to navigate.

BTW, the info text "When windows that display buffers associated with
process change their dimensions, the affected processes should be told
about these changes" seems to lack an "a" before "process".

And the text "If the process has the `adjust-window-size-function'
property (*note Process Information::), its value overrides the global
and buffer-local values of
`window-adjust-process-window-size-function'." is misleading.  Section
38.6 Process Information does not mention any such property and I have
no idea what it's supposed to accomplish.

martin