Compose buffer auto-height issues with variable-height fonts

[phil-s]

I just experienced a problem with enabling glyphless-display-mode from ement-room-compose-hook whereby the glyphless chars were rendered taller than the regular characters, and ement-room-compose-buffer-window-auto-height was then getting the height wrong, which I assume means window-body-height was returning the wrong value.

This might be related (if not specifically on account of glyphless-display-mode) to an issue @alphapapa experienced when testing the compose buffer enhancements.

With the window being not tall enough, it was scrolling by a line when point was at the bottom, thus hiding the top line.

Changing (window-body-height nil t) to (window-body-height nil 'remap) might resolve this? I'm not sure... my cursory test looked like it was producing a height where every line was the height of the taller characters, but that's an improvement on having the window not be tall enough.

That's not a fix on its own, though -- the actual resizing goes crazy, and I'm not sure the other functions which can behave PIXELWISE similarly handle a remap value for that argument.

A partial workaround could be new user options to set some top/bottom (or per-line?) pixelwise padding in these buffers. Because that could be a nice-to-have even in the absence of this bug, it might be a good thing to do if I can't figure out a fix. (Hopefully there's a nice fix for the actual issue, though, as that's a fragile workaround.)

n.b. What I actually did as a workaround was to just insert additional empty lines at the end of the message -- that at least restores visibility of the whole message, which helps to avoid the biggest problem.

Anyone hitting this persistently could also set a ement-room-compose-buffer-window-auto-height-min which was large enough that they wouldn't trigger the issue for average-length messages.

[alphapapa]

shrug I'm happy to leave this matter to you. Thanks for writing it up well. :)