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).
Per this answer, customized
t. Zero effect.
After digging some more, set
(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.