How to prevent the completion window from hogging up nearly whole frame (-3 lines)?

Question

One or the other of the various Emacsen has been, at different times, my one and only editor on all *nix systems¹. I usually use one X window per buffer, so I can arrange windows side by side, or use windows manager shortcuts to switch. So, one file, one tall 80x55 window. Fig 1.

When I hit TAB in the window above, I'm getting this (Fig 2). The temporary completion window hogs up all but 3 lines of the frame. The same exact thing happens in any edit mode, as long as the completion list is long enough.

Nothing really drastic happens, any cursor movement command dismisses the unhelpful completion window, but I'm visually lost in the file for a moment: if I was editing near the bottom of the frame, the contents of the buffer scrolls up, and what I might have looked at is now above the top of window.

I suspect, but won't claim under sworn oath, this behavior is new to Emacs 24. Before that, the completion buffer height was visually about half of the window height. And, fellow Emacsierres, it's annoying enough that it makes me swear at times without any oath in sight.

It is also worth noting that the problem affects only temporary completion windows. For example, Help on function or variable pops up at the bottom, taking exactly 1/2 window height, just the way I'm used to (Fig. 3).

---

I tried:

1. Per this answer, customized window-combination-resize to t. Zero effect.

2. After digging some more, set temp-buffer-max-height to (lambda (buffer) (/ (- (frame-height) 2) 2))². The size it computes is quite sensible (27 for my 55-line buffer). Nope, nothing changed. What troubles me here is that the totally nebulous computation that I removed (see the note² for details) did not affect anything.

I should make it clear that my other displays have 100% scaling, aren't close to 4K high-DPI and other buzzwords, but still the completion want all but 3 lines of the window and messes up my scrolling position of the file I edit. So high-DPI is certainly not part of the problem. I'm just writing this question on the go, from that high-DPI laptop.

I'm out of ideas, really, thanks for any help.

---

¹ Coincidentally, albeit not very relevant to the point, I'm responsible for a lot of C ad .el code in the once-wannabe-competitor project, XEmacs, likely more than half of its MS-windows-specific part, in the mid 1990s when Emacs updates slowed to nil, so I'm not exactly a n00b; but some stuff I forgot, and some things changed in these 25 years beyond recognition. By now, I should grade myself a n00b+, no higher. Please bear with me.

² The original value from help.el

(lambda (buffer)
  (if (and (display-graphic-p) (eq (selected-window) (frame-root-window)))
  (/ (x-display-pixel-height) (frame-char-height) 2)
    (/ (- (frame-height) 2) 2)))

was also sensible, but only as long as your font scaling is set to 100% on an MS Windows desktop. With a "high-DPI" laptop, the function produced nonsensical values. With my 200% font scaling, (x-display-pixel-height) returned exactly half screen pixel height, 1080 vs actual 2160, and (frame-char-height) 14 instead of actual 55, 4 times less--looks like the scaling was applied the wrong way, inconsistently, and twice. I do not know if this is an Emacs or the X Server issue, but anyway, I got rid of this bogus branch. I'm leaving this note for high-DPI users, just in case. Did me neither help nor harm, but was clearly wacky.

Answer 1

What troubles me here is that the totally nebulous computation that I removed did not affect anything.

And for a reason. The temp-buffer-max-height variable does not have any effect unless another variable, namely temp-buffer-resize-mode, is set to t. Both variables are customizable. This is kind of documented with the temp-buffer-max-height variable help:

This is effective only when Temp Buffer Resize mode is enabled.

This assumes that the reader is aware what does the “Temp Buffer Resize mode” do, how to tell if it is enabled, and how to enable it if it is not. I was not.

And yeah, my impression that the behavior is fairly recent was correct: looking at the change history, temp-buffer-max-height was added in the version 24.3.