From: Eli Zaretskii <eliz@gnu.org>
To: Gregory Heytings <ghe@sdf.org>
Cc: monnier@iro.umontreal.ca, 43519@debbugs.gnu.org
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Date: Mon, 21 Sep 2020 17:17:23 +0300 [thread overview]
Message-ID: <83tuvrxlho.fsf@gnu.org> (raw)
In-Reply-To: <alpine.NEB.2.22.394.2009210836270453.4535@sdf.lonestar.org> (message from Gregory Heytings on Mon, 21 Sep 2020 06:50:22 +0000)
> Date: Mon, 21 Sep 2020 06:50:22 +0000
> From: Gregory Heytings <ghe@sdf.org>
> cc: Stefan Monnier <monnier@iro.umontreal.ca>, 43519@debbugs.gnu.org
>
> It is "true that in all of these situations starting the mini-window display at BOB would DTRT", but it is also true that in all of these situations the height overflow is due to an overlay at EOB.
By "height overflow" you mean the fact that max-mini-window-height
screen lines aren't enough to display all of the stuff we want in the
mini-window? If so, you are considering only a narrow class of use
cases. In other use cases, we could have a very long prompt, for
example. Or we could even have a tall enough image there. Then
reasons for "overflow" could be different.
> So another solution, which I think would be even better, but might change the existing behavior marginally, would be to calculate the height two times, once at EOB and once at EOB-1.
This assumes that there's no overlay strings at EOB-1? Why would we
assume something like that? It again narrows the set of use cases
which will be handled properly.
It also seems to assume that the prompt (which ends at EOB) is much
shorter than the overlay string displayed beyond EOB. But this is not
guaranteed: it could be the other way around, in which case the
proposed changes will not show the most important part of the
mini-window's display.
My suggestion is to go back to the "start display at BOB" assertion
(which is not true in general), and try to find a more general/more
accurate one. For example: would it be okay to start the display at
the beginning of the screen line where we end up after
move_it_vertically_backward returns? This way, if the prompt is very
long, we will start in its middle (at the beginning of one of the
continuation lines used to display the prompt), but we will show as
much of the overlay string as possible. This strategy will also
handle minibuffer prompts that don't use overlay strings at all better
than if we start at BOB.
next prev parent reply other threads:[~2020-09-21 14:17 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-19 17:54 bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content Stefan Monnier
2020-09-19 18:52 ` Eli Zaretskii
2020-09-19 19:42 ` Stefan Monnier
2020-09-19 20:10 ` Eli Zaretskii
2020-09-19 22:06 ` Stefan Monnier
2020-09-20 8:52 ` Eli Zaretskii
2020-09-20 21:04 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-20 21:31 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-21 6:50 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-21 14:17 ` Eli Zaretskii [this message]
2020-09-21 15:02 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-21 15:33 ` Eli Zaretskii
2020-09-21 15:44 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-21 16:10 ` Eli Zaretskii
2020-09-21 16:27 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-21 17:30 ` Eli Zaretskii
2020-09-21 18:42 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-21 19:37 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-21 19:37 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-22 6:57 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-22 6:57 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-22 14:11 ` Eli Zaretskii
2020-09-22 15:52 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-22 16:10 ` Eli Zaretskii
2020-09-22 21:01 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-21 17:28 ` Stefan Monnier
2020-09-21 17:47 ` Eli Zaretskii
2020-09-21 18:45 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-21 19:37 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-22 6:58 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-22 14:14 ` Eli Zaretskii
2020-09-21 14:04 ` Eli Zaretskii
2020-09-21 14:31 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-21 14:47 ` Eli Zaretskii
2020-09-21 14:02 ` Eli Zaretskii
2020-09-21 14:18 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-21 14:45 ` Eli Zaretskii
2020-09-21 15:26 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-21 15:39 ` Eli Zaretskii
2020-09-21 16:00 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-20 22:40 ` Stefan Monnier
2020-09-21 7:04 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-21 14:05 ` Eli Zaretskii
2020-09-21 17:25 ` Stefan Monnier
2020-09-21 17:45 ` Eli Zaretskii
2020-09-21 19:17 ` Stefan Monnier
2020-09-21 19:47 ` Eli Zaretskii
2020-09-22 5:26 ` Eli Zaretskii
2020-09-22 14:00 ` Stefan Monnier
2020-09-22 14:02 ` Eli Zaretskii
2020-09-22 15:51 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-22 16:06 ` Eli Zaretskii
2020-09-22 16:17 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-22 16:47 ` Eli Zaretskii
2020-09-22 16:49 ` Eli Zaretskii
2020-09-22 20:06 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-23 2:40 ` Eli Zaretskii
2020-09-23 7:15 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-23 14:34 ` Eli Zaretskii
2020-09-21 20:05 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-21 20:49 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-23 18:35 ` Stefan Monnier
2020-09-22 6:58 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-22 6:58 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-20 1:00 ` bug#43519: (no subject) Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-20 6:08 ` Eli Zaretskii
2020-09-20 8:27 ` bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-20 9:03 ` Eli Zaretskii
2020-09-20 10:12 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-20 10:52 ` Eli Zaretskii
2020-09-20 19:50 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
[not found] <<jwvft7dveii.fsf@iro.umontreal.ca>
[not found] ` <<83wo0p1twr.fsf@gnu.org>
[not found] ` <<jwvh7rta7et.fsf-monnier+emacs@gnu.org>
[not found] ` <<83r1qx1q9v.fsf@gnu.org>
[not found] ` <<jwvzh5l8med.fsf-monnier+emacs@gnu.org>
[not found] ` <<838sd425l2.fsf@gnu.org>
[not found] ` <<jwvd02g5bnp.fsf-monnier+emacs@gnu.org>
[not found] ` <<83y2l3xm15.fsf@gnu.org>
[not found] ` <<jwvwo0n2hgh.fsf-monnier+emacs@gnu.org>
[not found] ` <<83eemvxbvg.fsf@gnu.org>
[not found] ` <<jwv363b2b48.fsf@iro.umontreal.ca>
[not found] ` <<837dsmykrn.fsf@gnu.org>
[not found] ` <<E1kKapF-0007yc-Mb@fencepost.gnu.org>
[not found] ` <<831ritykni.fsf@gnu.org>
[not found] ` <<alpine.NEB.2.22.394.2009221712130453.10035@sdf.lonestar.org>
[not found] ` <<83k0wlx0cz.fsf@gnu.org>
[not found] ` <<alpine.NEB.2.22.394.2009221808130453.16638@sdf.lonestar.org>
[not found] ` <<83d02dwyfa.fsf@gnu.org>
2020-09-22 20:03 ` Drew Adams
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=83tuvrxlho.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=43519@debbugs.gnu.org \
--cc=ghe@sdf.org \
--cc=monnier@iro.umontreal.ca \
/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).