* bug#50178: 28.0.50; Size of echo area does not account for line-spacing @ 2021-08-24 2:08 Óscar Fuentes 2021-08-24 11:58 ` Eli Zaretskii 0 siblings, 1 reply; 21+ messages in thread From: Óscar Fuentes @ 2021-08-24 2:08 UTC (permalink / raw) To: 50178 Seems that on some circunstances the vertical space calculated for the text on the echo area does not account for the value of line-spacing: emacs -Q M-x icomplete-vertical-mode M-x fido-mode (set-default 'line-spacing 0.1) Now M-x will display a list of candidates with the last candidate partially visible for lack of vertical space. In GNU Emacs 28.0.50 (build 4, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0) of 2021-07-30 built on sky Repository revision: d9bc7dbefd88995d04b9843f521d82118265fecf Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12011000 System Description: Debian GNU/Linux 11 (bullseye) Configured using: 'configure --with-native-compilation --without-toolkit-scroll-bars --with-x-toolkit=lucid --with-modules --without-imagemagick build_alias= host_alias= target_alias=' Configured features: CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON LIBOTF LIBSELINUX LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF X11 XAW3D XDBE XIM XPM LUCID ZLIB ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#50178: 28.0.50; Size of echo area does not account for line-spacing 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 0 siblings, 1 reply; 21+ messages in thread From: Eli Zaretskii @ 2021-08-24 11:58 UTC (permalink / raw) To: Óscar Fuentes; +Cc: 50178 > From: Óscar Fuentes <ofv@wanadoo.es> > Date: Tue, 24 Aug 2021 04:08:41 +0200 > > Seems that on some circunstances the vertical space calculated for the > text on the echo area does not account for the value of line-spacing: > > emacs -Q > M-x icomplete-vertical-mode > M-x fido-mode > (set-default 'line-spacing 0.1) > > Now M-x will display a list of candidates with the last candidate > partially visible for lack of vertical space. And why is that a problem? Emacs displays partially visible lines at end of window in many cases; as long as the list of completion candidates is long enough, you cannot see all of them anyway. Or maybe you have a specific recipe in mind where this works incorrectly, in which case please show that recipe. Thanks. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#50178: 28.0.50; Size of echo area does not account for line-spacing 2021-08-24 11:58 ` Eli Zaretskii @ 2021-08-24 13:34 ` Óscar Fuentes 2021-08-24 16:20 ` Eli Zaretskii 0 siblings, 1 reply; 21+ messages in thread From: Óscar Fuentes @ 2021-08-24 13:34 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 50178 Eli Zaretskii <eliz@gnu.org> writes: > And why is that a problem? Emacs displays partially visible lines at > end of window in many cases; as long as the list of completion > candidates is long enough, you cannot see all of them anyway. > > Or maybe you have a specific recipe in mind where this works > incorrectly, in which case please show that recipe. There are some packages that works displaying a certain number of lines on the echo area (ido-grid-mode, for instance.) They set max-mini-window-height to an integer and expect that Emacs will take care of resizing the echo area accordingly, if possible. If the resulting echo area is not tall enough, there is a problem. 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. Otherwise every one of those packages must implement the heuristics for taking into account `line-spacing' and any other present and future variable that might affect the number of lines visible on the echo area. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#50178: 28.0.50; Size of echo area does not account for line-spacing 2021-08-24 13:34 ` Óscar Fuentes @ 2021-08-24 16:20 ` Eli Zaretskii 2021-08-24 17:44 ` Óscar Fuentes 0 siblings, 1 reply; 21+ messages in thread From: Eli Zaretskii @ 2021-08-24 16:20 UTC (permalink / raw) To: Óscar Fuentes; +Cc: 50178 > From: Óscar Fuentes <ofv@wanadoo.es> > Cc: 50178@debbugs.gnu.org > Date: Tue, 24 Aug 2021 15:34:27 +0200 > > There are some packages that works displaying a certain number of lines > on the echo area (ido-grid-mode, for instance.) They set > max-mini-window-height to an integer and expect that Emacs will take > care of resizing the echo area accordingly, if possible. If the > resulting echo area is not tall enough, there is a problem. > > 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. 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. So once again, I see no problem here, it's just Emacs display working as designed in the face of variable-size fonts and window heights that aren't necessarily an integral multiple of the font/line height. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#50178: 28.0.50; Size of echo area does not account for line-spacing 2021-08-24 16:20 ` Eli Zaretskii @ 2021-08-24 17:44 ` Óscar Fuentes 2021-08-24 18:13 ` Eli Zaretskii 0 siblings, 1 reply; 21+ messages in thread From: Óscar Fuentes @ 2021-08-24 17:44 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 50178 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#50178: 28.0.50; Size of echo area does not account for line-spacing 2021-08-24 17:44 ` Óscar Fuentes @ 2021-08-24 18:13 ` Eli Zaretskii 2021-08-24 18:38 ` Óscar Fuentes 0 siblings, 1 reply; 21+ messages in thread From: Eli Zaretskii @ 2021-08-24 18:13 UTC (permalink / raw) To: Óscar Fuentes; +Cc: 50178 > From: Óscar Fuentes <ofv@wanadoo.es> > Cc: 50178@debbugs.gnu.org > Date: Tue, 24 Aug 2021 19:44:37 +0200 > X-Spam-Status: No > > > 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. But the former is basically impossible to provide, not in Emacs 21+ with its support for variable-size fonts and display of images and xwidgets as part of text. Even with just different fonts, N lines using font of size X are not the same as N lines with size Y. > 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. No, max-mini-window-height is consistent with how we size all the windows in Emacs: in units of the canonical character height and width. That's our usual paradigm. > 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. It would mean a different height for each piece of text you display. It will cause the mode line to jump up and down like a wild goat, even if a message applies some innocent non-default faces. It's not how Emacs is designed to work. It basically works in pixels, not in lines, and just converts from and to canonical character units to make it easier for users to specify values. > > 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. ??? Of course, I can. What do you mean by "you can't"? The mini-window is just another window, so as long as you can make it the selected window (e.g., when the minibuffer is active), you can navigate there. > 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 recipe you show in the bug report does support scrolling: the up- and down-arrow keys scroll the list of candidates. > 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. There was no ido-grid-mode in the original report, so I guess you are now talking about a different recipe? Can you present it? We could then discuss those problems and what can be done about that. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#50178: 28.0.50; Size of echo area does not account for line-spacing 2021-08-24 18:13 ` Eli Zaretskii @ 2021-08-24 18:38 ` Óscar Fuentes 2021-08-24 18:49 ` Eli Zaretskii 0 siblings, 1 reply; 21+ messages in thread From: Óscar Fuentes @ 2021-08-24 18:38 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 50178 Eli Zaretskii <eliz@gnu.org> writes: >> 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. > > But the former is basically impossible to provide, not in Emacs 21+ > with its support for variable-size fonts and display of images and > xwidgets as part of text. Even with just different fonts, N lines > using font of size X are not the same as N lines with size Y. We are talking about the mini window here. It's contents are much more restricted, in the sense that it is determined by some command. This bug report is about such command wanting to show at least N lines, using the current display settings (font, line spacing, etc). >> You can't navigate around on the contents of the mini-window. > > ??? Of course, I can. What do you mean by "you can't"? The > mini-window is just another window, so as long as you can make it the > selected window (e.g., when the minibuffer is active), you can > navigate there. Allowing the user to move around on the mini window possibly is at odds with the UI of the command using the mini window. Certainly, it would be an inconvenience, as I mentioned before. >> 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 recipe you show in the bug report does support scrolling: the up- > and down-arrow keys scroll the list of candidates. Yes, that was just an example for demonstrating the problem using stock Emacs. Curiously, something like (message "foo1\nfoo2\nfoo3\nfoo4\nfoo4\nfoo5\nfoo6\nfoo7\nfoo8") doesn't show truncated lines because it apparently ignores the value of line-spacing. > There was no ido-grid-mode in the original report, so I guess you are > now talking about a different recipe? Can you present it? We could > then discuss those problems and what can be done about that. ido-grid-mode does not support vertical scrolling (it is not supposed to do that and it would be a burden if it did) and with certain values of line-spacing the last line(s) are partially visible or invisible. It's as simple as that. It uses max-mini-window-height for ensuring that the text fits on the mini-window, but that doesn't work on the presence of line-spacing. One workround would be to locally set line-spacing to nil (overriding the user's preferences), but this does not protect against other current or future settings that might affect how the lines are rendered. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#50178: 28.0.50; Size of echo area does not account for line-spacing 2021-08-24 18:38 ` Óscar Fuentes @ 2021-08-24 18:49 ` Eli Zaretskii 2021-08-24 19:36 ` Óscar Fuentes 0 siblings, 1 reply; 21+ messages in thread From: Eli Zaretskii @ 2021-08-24 18:49 UTC (permalink / raw) To: Óscar Fuentes; +Cc: 50178 > From: Óscar Fuentes <ofv@wanadoo.es> > Cc: 50178@debbugs.gnu.org > Date: Tue, 24 Aug 2021 20:38:56 +0200 > > Eli Zaretskii <eliz@gnu.org> writes: > > > But the former is basically impossible to provide, not in Emacs 21+ > > with its support for variable-size fonts and display of images and > > xwidgets as part of text. Even with just different fonts, N lines > > using font of size X are not the same as N lines with size Y. > > We are talking about the mini window here. It's contents are much more > restricted, in the sense that it is determined by some command. I don't really see how can we say that, given the proliferation of the various completion packages, which display everything that can be displayed in the mini-window. > This bug report is about such command wanting to show at least N > lines, using the current display settings (font, line spacing, etc). And I still don't understand what is wrong with the recipe you've shown. In my testing, I see a very long list of candidates, with several ones fully visible and one visible only partially. I can scroll down the list to see more candidates, including the one which was initially displayed partially. I fail to see a problem with that, sorry. > >> You can't navigate around on the contents of the mini-window. > > > > ??? Of course, I can. What do you mean by "you can't"? The > > mini-window is just another window, so as long as you can make it the > > selected window (e.g., when the minibuffer is active), you can > > navigate there. > > Allowing the user to move around on the mini window possibly is at odds > with the UI of the command using the mini window. Certainly, it would be > an inconvenience, as I mentioned before. Again, I don't see any inconvenience. It's just the normal vertical motion of the cursor, not unlike any other window. > Curiously, something like > > (message "foo1\nfoo2\nfoo3\nfoo4\nfoo4\nfoo5\nfoo6\nfoo7\nfoo8") > > doesn't show truncated lines because it apparently ignores the value of > line-spacing. It does here, I guess you didn't turn line-spacing by default or something. Try emacs -Q --eval "(setq-default line-spacing 0.2)" > ido-grid-mode does not support vertical scrolling (it is not supposed to > do that and it would be a burden if it did) and with certain values of > line-spacing the last line(s) are partially visible or invisible. It's > as simple as that. It uses max-mini-window-height for ensuring that the > text fits on the mini-window, but that doesn't work on the presence of > line-spacing. > > One workround would be to locally set line-spacing to nil (overriding > the user's preferences), but this does not protect against other current > or future settings that might affect how the lines are rendered. Or it could calculate max-mini-window-height more accurately. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#50178: 28.0.50; Size of echo area does not account for line-spacing 2021-08-24 18:49 ` Eli Zaretskii @ 2021-08-24 19:36 ` Óscar Fuentes 2021-08-25 2:24 ` Eli Zaretskii 0 siblings, 1 reply; 21+ messages in thread From: Óscar Fuentes @ 2021-08-24 19:36 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 50178 Eli Zaretskii <eliz@gnu.org> writes: >> One workround would be to locally set line-spacing to nil (overriding >> the user's preferences), but this does not protect against other current >> or future settings that might affect how the lines are rendered. > > Or it could calculate max-mini-window-height more accurately. It must know and handle every setting that affects line height, current and future. It would be handy if Emacs provided a function that does that. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#50178: 28.0.50; Size of echo area does not account for line-spacing 2021-08-24 19:36 ` Óscar Fuentes @ 2021-08-25 2:24 ` Eli Zaretskii 2021-08-25 7:49 ` martin rudalics 0 siblings, 1 reply; 21+ messages in thread From: Eli Zaretskii @ 2021-08-25 2:24 UTC (permalink / raw) To: Óscar Fuentes; +Cc: 50178 > From: Óscar Fuentes <ofv@wanadoo.es> > Cc: 50178@debbugs.gnu.org > Date: Tue, 24 Aug 2021 21:36:58 +0200 > > Eli Zaretskii <eliz@gnu.org> writes: > > > Or it could calculate max-mini-window-height more accurately. > > It must know and handle every setting that affects line height, current > and future. It would be handy if Emacs provided a function that does > that. We already have it: window-text-pixel-size. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#50178: 28.0.50; Size of echo area does not account for line-spacing 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 0 siblings, 2 replies; 21+ messages in thread From: martin rudalics @ 2021-08-25 7:49 UTC (permalink / raw) To: Eli Zaretskii, Óscar Fuentes; +Cc: 50178 >> It must know and handle every setting that affects line height, current >> and future. It would be handy if Emacs provided a function that does >> that. > > We already have it: window-text-pixel-size. To elaborate: (1) You first have to calculate the maximum permissible pixel height of the echo area window from the character height of the frame where you intend to display the completions and the value of `max-mini-window-height' height as specified for that frame. Note that for a minibuffer-less frame the echo area window may appear on another frame whose character height you have to use here. (2) You then have to calculate the pixel height of each completion line as if it were shown in the echo area window mentioned in (1) using `window-text-pixel-size' and add it to some cumulative height until you have exhausted the maximum permissible height calculated in (1). martin ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#50178: 28.0.50; Size of echo area does not account for line-spacing 2021-08-25 7:49 ` martin rudalics @ 2021-08-25 9:01 ` Gregory Heytings 2021-08-25 10:49 ` Óscar Fuentes 1 sibling, 0 replies; 21+ messages in thread From: Gregory Heytings @ 2021-08-25 9:01 UTC (permalink / raw) To: martin rudalics; +Cc: Óscar Fuentes, 50178 > > To elaborate: > > (1) You first have to calculate the maximum permissible pixel height of > the echo area window from the character height of the frame where you > intend to display the completions and the value of > `max-mini-window-height' height as specified for that frame. Note that > for a minibuffer-less frame the echo area window may appear on another > frame whose character height you have to use here. > > (2) You then have to calculate the pixel height of each completion line > as if it were shown in the echo area window mentioned in (1) using > `window-text-pixel-size' and add it to some cumulative height until you > have exhausted the maximum permissible height calculated in (1). > If you can live with the fact that the last visible completion candidate is not fully displayed (which is, as Eli said, consistent with what happens in other Emacs windows), this complex procedure is not necessary anymore. You can simply set redisplay-adhoc-scroll-in-resize-mini-windows to nil and insert "enough" completion candidates. Emacs will resize the window appropriately, and the last completion candidates will not be visible. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#50178: 28.0.50; Size of echo area does not account for line-spacing 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 ` (2 more replies) 1 sibling, 3 replies; 21+ messages in thread From: Óscar Fuentes @ 2021-08-25 10:49 UTC (permalink / raw) To: martin rudalics; +Cc: 50178-done martin rudalics <rudalics@gmx.at> writes: >>> It must know and handle every setting that affects line height, current >>> and future. It would be handy if Emacs provided a function that does >>> that. >> >> We already have it: window-text-pixel-size. > > To elaborate: > > (1) You first have to calculate the maximum permissible pixel height of > the echo area window from the character height of the frame where > you intend to display the completions and the value of > `max-mini-window-height' height as specified for that frame. Note > that for a minibuffer-less frame the echo area window may appear on > another frame whose character height you have to use here. > > (2) You then have to calculate the pixel height of each completion line > as if it were shown in the echo area window mentioned in (1) using > `window-text-pixel-size' and add it to some cumulative height until > you have exhausted the maximum permissible height calculated in (1). Thanks. That's too complicated and looks like there are quite a bit of hidden traps, so for the time being I'll set line-spacing to nil. On true pixel-oriented systems there are APIs for querying the display engine about several metrics. Then you can place the text at certain pixel coordinates. Emacs, however, is a Frankenstein system, that uses pixels (on graphic frames) but the text positioning depends on previous text, i.e. for vertical positioning it is a line-based, not pixel-based, system. Therefore, when you just need to output some lines, you must deal with pixels, translate back to lines and, to add insult to injury, resort to post-facto information. As useful as it would be an API that returns how many lines fit on a given window. Or, on this case, max-mini-window-height being a true indication of the capacity of the mini window on terms of the current display settings, which is what the users want 99.9% of the time. Closing. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#50178: 28.0.50; Size of echo area does not account for line-spacing 2021-08-25 10:49 ` Óscar Fuentes @ 2021-08-25 12:15 ` Eli Zaretskii 2021-08-25 14:33 ` Gregory Heytings 2021-08-26 7:54 ` martin rudalics 2 siblings, 0 replies; 21+ messages in thread From: Eli Zaretskii @ 2021-08-25 12:15 UTC (permalink / raw) To: Óscar Fuentes; +Cc: 50178 > From: Óscar Fuentes <ofv@wanadoo.es> > Cc: Eli Zaretskii <eliz@gnu.org>, 50178-done@debbugs.gnu.org > Date: Wed, 25 Aug 2021 12:49:39 +0200 > > As useful as it would be an API that returns how many lines fit on a > given window. What is a "line" for this purpose? The notion of a "canonical line" is well defined, and that is what we use. Any other notion will have to be defined first, and it isn't easy, I can tell you. > Or, on this case, max-mini-window-height being a true > indication of the capacity of the mini window on terms of the current > display settings, which is what the users want 99.9% of the time. Unless you counted only yourself in those 99.9%, it is a strange thing to say about the modern Emacs. It's as if you wanted to go back to Emacs 18, where all lines were the same height. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#50178: 28.0.50; Size of echo area does not account for line-spacing 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-26 7:54 ` martin rudalics 2 siblings, 1 reply; 21+ messages in thread From: Gregory Heytings @ 2021-08-25 14:33 UTC (permalink / raw) To: Óscar Fuentes; +Cc: 50178-done > > On true pixel-oriented systems there are APIs for querying the display > engine about several metrics. Then you can place the text at certain > pixel coordinates. Emacs, however, is a Frankenstein system, that uses > pixels (on graphic frames) but the text positioning depends on previous > text, i.e. for vertical positioning it is a line-based, not pixel-based, > system. Therefore, when you just need to output some lines, you must > deal with pixels, translate back to lines and, to add insult to injury, > resort to post-facto information. > > As useful as it would be an API that returns how many lines fit on a > given window. Or, on this case, max-mini-window-height being a true > indication of the capacity of the mini window on terms of the current > display settings, which is what the users want 99.9% of the time. > Try emacs -Q, C-h h to see why it is impossible to have "an API that returns how many lines fit on a given window". ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#50178: 28.0.50; Size of echo area does not account for line-spacing 2021-08-25 14:33 ` Gregory Heytings @ 2021-08-25 17:09 ` Óscar Fuentes 2021-08-25 17:57 ` Eli Zaretskii 0 siblings, 1 reply; 21+ messages in thread From: Óscar Fuentes @ 2021-08-25 17:09 UTC (permalink / raw) To: Gregory Heytings; +Cc: 50178-done Gregory Heytings <gregory@heytings.org> writes: > Try emacs -Q, C-h h to see why it is impossible to have "an API that > returns how many lines fit on a given window". Any graphics environment worth its salt has methods for measuring whatever object without actually rendering it. It's also true that those systems work on pixels (or some other suitable, fine-grained unit) all the way, they do not reveal themselves as TTY-oriented systems when the user says "ok, then put this right here." The impossibility you mention is a limitation of Emacs. So going back to Emacs, the doctstring of max-mini-window-height is "... If an integer, it specifies the maximum height in units of the mini-window frame’s default font’s height. " Why that was implemented that way? (instead of using pixels, for instance.) Maybe because the relevant use case was to support resizing the mini window on a way that guarantees that certain number of lines (rendered on the default font) will fit on it? ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#50178: 28.0.50; Size of echo area does not account for line-spacing 2021-08-25 17:09 ` Óscar Fuentes @ 2021-08-25 17:57 ` Eli Zaretskii 2021-08-25 20:10 ` Óscar Fuentes 0 siblings, 1 reply; 21+ messages in thread From: Eli Zaretskii @ 2021-08-25 17:57 UTC (permalink / raw) To: Óscar Fuentes; +Cc: gregory, 50178 > From: Óscar Fuentes <ofv@wanadoo.es> > Date: Wed, 25 Aug 2021 19:09:14 +0200 > Cc: 50178-done@debbugs.gnu.org > > Gregory Heytings <gregory@heytings.org> writes: > > > Try emacs -Q, C-h h to see why it is impossible to have "an API that > > returns how many lines fit on a given window". > > Any graphics environment worth its salt has methods for measuring > whatever object without actually rendering it. So does Emacs: that's what window-text-pixel-size does. > If an integer, it specifies the maximum height in units of the > mini-window frame’s default font’s height. > " > > Why that was implemented that way? (instead of using pixels, for > instance.) Because in most cases it's more useful: it approximates the actual number of lines quite well. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#50178: 28.0.50; Size of echo area does not account for line-spacing 2021-08-25 17:57 ` Eli Zaretskii @ 2021-08-25 20:10 ` Óscar Fuentes 2021-08-26 6:34 ` Eli Zaretskii 0 siblings, 1 reply; 21+ messages in thread From: Óscar Fuentes @ 2021-08-25 20:10 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gregory, 50178 Eli Zaretskii <eliz@gnu.org> writes: >> Any graphics environment worth its salt has methods for measuring >> whatever object without actually rendering it. > > So does Emacs: that's what window-text-pixel-size does. You missed the part "without actually rendering it". As per Martin's instructions, the method for ensuring that the text does not overflow the window is to put text on it, one line at a time, and watch the used space (I guess that two lines would be enough to extrapolate the space required by N lines assuming that the text is rendered with the default font, face, etc) On the case of ido-grid-mode (which displays a grid N lines tall that virtually expands horizontally) not knowing in advance how many lines are available means that it must populate the mini window with some dummy text to measure its capacity, throw away its contents and proceed to fill the mini window with the real payload. >> If an integer, it specifies the maximum height in units of the >> mini-window frame’s default font’s height. >> " >> >> Why that was implemented that way? (instead of using pixels, for >> instance.) > > Because in most cases it's more useful: it approximates the actual > number of lines quite well. Exactly, that was my point all along. And it would be a better approximation if the display engine used that variable taking into account line-spacing and other relevant settings which affect how the actual text is rendered. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#50178: 28.0.50; Size of echo area does not account for line-spacing 2021-08-25 20:10 ` Óscar Fuentes @ 2021-08-26 6:34 ` Eli Zaretskii 0 siblings, 0 replies; 21+ messages in thread From: Eli Zaretskii @ 2021-08-26 6:34 UTC (permalink / raw) To: Óscar Fuentes; +Cc: gregory, 50178 > From: Óscar Fuentes <ofv@wanadoo.es> > Cc: gregory@heytings.org, 50178@debbugs.gnu.org > Date: Wed, 25 Aug 2021 22:10:03 +0200 > > Eli Zaretskii <eliz@gnu.org> writes: > > >> Any graphics environment worth its salt has methods for measuring > >> whatever object without actually rendering it. > > > > So does Emacs: that's what window-text-pixel-size does. > > You missed the part "without actually rendering it". No, I didn't. window-text-pixel-size doesn't render the text, it _simulates_ its rendering internally. You can look at its source if you don't believe me. > As per Martin's instructions, the method for ensuring that the text does > not overflow the window is to put text on it, one line at a time, and > watch the used space (I guess that two lines would be enough to > extrapolate the space required by N lines assuming that the text is > rendered with the default font, face, etc) Martin's instructions notwithstanding, I stand by what I wrote. Yes, you need a window to compute the metrics, but that's only because some of the factors that determine the metrics can vary between windows. The window you pass to window-text-pixel-size doesn't need to be the same window where you will eventually display the text, it just should have the same window-specific parameters as the eventual one. > On the case of ido-grid-mode (which displays a grid N lines tall that > virtually expands horizontally) not knowing in advance how many lines > are available means that it must populate the mini window with some > dummy text to measure its capacity, throw away its contents and proceed > to fill the mini window with the real payload. Your conclusions are incorrect. Are you familiar with fit-window-to-buffer? Do you know that Help commands use that every time to dynamically decide how to size the window showing help? If so, doesn't the fact that this mechanism exists and works contradict your conclusions from what was said here? > >> Why that was implemented that way? (instead of using pixels, for > >> instance.) > > > > Because in most cases it's more useful: it approximates the actual > > number of lines quite well. > > Exactly, that was my point all along. And it would be a better > approximation if the display engine used that variable taking into > account line-spacing and other relevant settings which affect how the > actual text is rendered. I said "in most cases". It is impossible to do that in all cases. The case you are talking about is one of the rare exceptions. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#50178: 28.0.50; Size of echo area does not account for line-spacing 2021-08-25 10:49 ` Óscar Fuentes 2021-08-25 12:15 ` Eli Zaretskii 2021-08-25 14:33 ` Gregory Heytings @ 2021-08-26 7:54 ` martin rudalics 2021-08-26 8:12 ` Eli Zaretskii 2 siblings, 1 reply; 21+ messages in thread From: martin rudalics @ 2021-08-26 7:54 UTC (permalink / raw) To: Óscar Fuentes; +Cc: 50178-done > On true pixel-oriented systems there are APIs for querying the display > engine about several metrics. Then you can place the text at certain > pixel coordinates. Emacs, however, is a Frankenstein system, that uses > pixels (on graphic frames) but the text positioning depends on previous > text, i.e. for vertical positioning it is a line-based, not pixel-based, > system. Therefore, when you just need to output some lines, you must > deal with pixels, translate back to lines and, to add insult to injury, > resort to post-facto information. Users think in terms of lines and columns. True pixel-oriented systems are not convenient for editing. A few days ago I spent a couple of hours to remove one single line from a pdf-document using LibreOffice. I almost succeeded. > As useful as it would be an API that returns how many lines fit on a > given window. Or, on this case, max-mini-window-height being a true > indication of the capacity of the mini window on terms of the current > display settings, which is what the users want 99.9% of the time. Did you try with `redisplay-adhoc-scroll-in-resize-mini-windows' as Gregory proposed? martin ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#50178: 28.0.50; Size of echo area does not account for line-spacing 2021-08-26 7:54 ` martin rudalics @ 2021-08-26 8:12 ` Eli Zaretskii 0 siblings, 0 replies; 21+ messages in thread From: Eli Zaretskii @ 2021-08-26 8:12 UTC (permalink / raw) To: martin rudalics; +Cc: ofv, 50178 > Cc: Eli Zaretskii <eliz@gnu.org>, 50178-done@debbugs.gnu.org > From: martin rudalics <rudalics@gmx.at> > Date: Thu, 26 Aug 2021 09:54:51 +0200 > > > On true pixel-oriented systems there are APIs for querying the display > > engine about several metrics. Then you can place the text at certain > > pixel coordinates. Emacs, however, is a Frankenstein system, that uses > > pixels (on graphic frames) but the text positioning depends on previous > > text, i.e. for vertical positioning it is a line-based, not pixel-based, > > system. Therefore, when you just need to output some lines, you must > > deal with pixels, translate back to lines and, to add insult to injury, > > resort to post-facto information. > > Users think in terms of lines and columns. True pixel-oriented systems > are not convenient for editing. Yes. Most users won't know the pixel height and width of what we call "the canonical character" in Emacs. I only know that because I hack the display code (which works almost entirely in pixels) frequently enough to have those values burned into my memory, and even that only on my main development system. So the average users out there would be unable to specify dimensions in pixels, as the dimensions they have in mind are in lines and columns. ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2021-08-26 8:12 UTC | newest] Thread overview: 21+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 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
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).