unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Óscar Fuentes" <ofv@wanadoo.es>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 50178@debbugs.gnu.org
Subject: bug#50178: 28.0.50; Size of echo area does not account for line-spacing
Date: Tue, 24 Aug 2021 19:44:37 +0200	[thread overview]
Message-ID: <875yvug2ka.fsf@telefonica.net> (raw)
In-Reply-To: <837dgax1a0.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 24 Aug 2021 19:20:23 +0300")

Eli Zaretskii <eliz@gnu.org> writes:

>> IMO max-mini-window-height, when set to an integer, should mean "I want
>> this many lines", as it does when line-spacing is nil.
>
> But that's not the exact meaning of the value of that variable.  The
> doc string says:
>
>   If an integer, it specifies the maximum height in units of the
>   mini-window frame’s default font’s height.     ^^^^^^^^^^^^^^^
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> It is measured in units of the canonical character height, and that
> doesn't take the line-spacing into account, like it doesn't take into
> account faces that change the font or the size of the characters.
>
> IOW, the value means "this many lines", but assuming that the line's
> height is the one you get with the frame's default font.

IMAO the case where the user wants to ensure that the mini window is
capable of displaying at least X lines is much more common than the user
wanting a height of at least X times the default font's height.
Crucially, the first case is about showing information, while the second
is about aesthetics (suppossing that it is used at all with that
intention.)

I suspect that max-mini-window-height was introduced with the former use
case in mind, but was not updated when line-spacing was implemented
later.

If we have no method for ensuring that the echo area is capable of
displaying at least X lines (within some reasonable limits) then we need
one.

> You get the same in a window other than mini-window: if you set
> line-spacing, chances are the last screen line will be only partially
> visible.  Why should the mini-window be different? it's just another
> window.

You can't navigate around on the contents of the mini-window. If a
package can't rely on setting max-mini-window-height for showing certain
number of lines on the mini-window, then it must implement vertical
scrolling, which makes things complex both on the programming side and
on the UI side, just to make sure that the user can access the content's
of the overflowing line(s), if any.

The case of ido-grid-mode is glaring: it has a defcustom for setting how
many lines to show. When the command is invoked, it sets
max-mini-window-height accordingly (what else could it do?) but if
line-spacing is not nil, the bottom line(s) might not be visible.





  reply	other threads:[~2021-08-24 17:44 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-24  2:08 bug#50178: 28.0.50; Size of echo area does not account for line-spacing Óscar Fuentes
2021-08-24 11:58 ` Eli Zaretskii
2021-08-24 13:34   ` Óscar Fuentes
2021-08-24 16:20     ` Eli Zaretskii
2021-08-24 17:44       ` Óscar Fuentes [this message]
2021-08-24 18:13         ` Eli Zaretskii
2021-08-24 18:38           ` Óscar Fuentes
2021-08-24 18:49             ` Eli Zaretskii
2021-08-24 19:36               ` Óscar Fuentes
2021-08-25  2:24                 ` Eli Zaretskii
2021-08-25  7:49                   ` martin rudalics
2021-08-25  9:01                     ` Gregory Heytings
2021-08-25 10:49                     ` Óscar Fuentes
2021-08-25 12:15                       ` Eli Zaretskii
2021-08-25 14:33                       ` Gregory Heytings
2021-08-25 17:09                         ` Óscar Fuentes
2021-08-25 17:57                           ` Eli Zaretskii
2021-08-25 20:10                             ` Óscar Fuentes
2021-08-26  6:34                               ` Eli Zaretskii
2021-08-26  7:54                       ` martin rudalics
2021-08-26  8:12                         ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=875yvug2ka.fsf@telefonica.net \
    --to=ofv@wanadoo.es \
    --cc=50178@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).