From: Gregory Heytings via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: 43572@debbugs.gnu.org
Subject: bug#43572: Feature request: make it possible to choose whether the first lines of the minibuffer should be displayed instead of the last ones
Date: Tue, 22 Sep 2020 20:57:13 +0000 [thread overview]
Message-ID: <alpine.NEB.2.22.394.2009222215560453.32542@sdf.lonestar.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 2205 bytes --]
In Emacs 27.1, the mini-window displays the last lines of the minibuffer.
This is, in general, the desired behavior, but in some cases it is not.
One case in which this behavior is not desirable is when completion
candidates are displayed with an overlay at the end of the buffer. When
this overlay is taller than max-mini-window-height, the prompt and the
user input so far disappear. A simple example: M-: (setq
max-mini-window-height 1), M-x icomplete-mode, M-x a.
Because of this behavior, and because it is counter-intuitive / not
user-friendly when the prompt and user input so far disappear, those who
create programs that display such completion candidates have been
struggling to create overlays in such a way that they are (together with
the prompt and the user input so far) not taller than
max-mini-window-height. Doing this is, in general, far from trivial.
The attached patch makes it possible to (selectively) choose to display
the _first_ lines of the minibuffer instead of its _last_ lines (which is
and remains the default behavior). This means that displaying completion
candidates becomes a trivial task: it suffices to create an overlay with
completion candidates, without worrying at all about its size (or about
the size of the prompt and user input), and as many of these candidates as
possible will automatically be displayed.
For example, implementing vertical icomplete only requires:
(setq icomplete-separator "\n")
(add-hook 'icomplete-minibuffer-setup-hook (lambda () (setq start-display-at-beginning-of-minibuffer t)))
This feature request follows the discussion in bug#43519. The change
proposed there by Eli Zaretskii improves the behavior w.r.t. Emacs 27.1,
but it is still suboptimal to display completion candidates in a
user-friendly way. For example:
Find file: <user input>|
<completion candidates>
(where | represents the cursor) will become:
<user input>|
<completion candidates>
when the user input becomes larger than a line. That is, the "Find file:"
prompt and the user input on the first line will disappear.
The attached patch does not change the behavior of Emacs in any way,
unless the feature it introduces is used.
[-- Attachment #2: Type: text/x-diff, Size: 2129 bytes --]
diff --git a/src/minibuf.c b/src/minibuf.c
index f957b2ae17..44852127ed 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -657,6 +657,8 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
if (STRINGP (input_method) && !NILP (Ffboundp (Qactivate_input_method)))
call1 (Qactivate_input_method, input_method);
+ Vstart_display_at_beginning_of_minibuffer = Qnil;
+
run_hook (Qminibuffer_setup_hook);
/* Don't allow the user to undo past this point. */
@@ -2097,6 +2099,15 @@ syms_of_minibuf (void)
uses to hide passwords. */);
Vread_hide_char = Qnil;
+ DEFVAR_LISP ("start-display-at-beginning-of-minibuffer", Vstart_display_at_beginning_of_minibuffer,
+ doc: /* Whether to preferably display the beginning of the minibuffer.
+When the mini-window is not large enough to display the complete minibuffer,
+the default behavior is to display the last part of the minibuffer and to
+hide its first part. This variable reverses that behavior. This variable
+is reset when the minibuffer is entered, and must be set in
+`minibuffer-setup-hook'. */);
+ Vstart_display_at_beginning_of_minibuffer = Qnil;
+
defsubr (&Sactive_minibuffer_window);
defsubr (&Sset_minibuffer_window);
defsubr (&Sread_from_minibuffer);
diff --git a/src/xdisp.c b/src/xdisp.c
index 49225c56fe..1b1a34b97f 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -11804,7 +11804,7 @@ resize_mini_window (struct window *w, bool exact_p)
}
/* Compute a suitable window start. */
- if (height > max_height)
+ if (height > max_height && !EQ (Vstart_display_at_beginning_of_minibuffer, Qt))
{
height = (max_height / unit) * unit;
init_iterator (&it, w, ZV, ZV_BYTE, NULL, DEFAULT_FACE_ID);
@@ -11812,7 +11812,10 @@ resize_mini_window (struct window *w, bool exact_p)
start = it.current.pos;
}
else
- SET_TEXT_POS (start, BEGV, BEGV_BYTE);
+ {
+ if (height > max_height) height = (max_height / unit) * unit;
+ SET_TEXT_POS (start, BEGV, BEGV_BYTE);
+ }
SET_MARKER_FROM_TEXT_POS (w->start, start);
next reply other threads:[~2020-09-22 20:57 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-22 20:57 Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2020-09-23 15:17 ` bug#43572: Feature request: make it possible to choose whether the first lines of the minibuffer should be displayed instead of the last ones Eli Zaretskii
2020-09-23 19:15 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-23 19:37 ` Eli Zaretskii
2020-09-23 20:15 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-24 14:24 ` Eli Zaretskii
2020-09-24 14:41 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-24 15:11 ` Eli Zaretskii
2020-09-24 16:09 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-24 16:20 ` Eli Zaretskii
2020-09-24 16:40 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-24 17:03 ` Eli Zaretskii
2020-09-24 21:51 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-25 6:59 ` Eli Zaretskii
2020-09-25 8:34 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-25 9:14 ` Eli Zaretskii
2020-09-25 10:14 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-25 11:17 ` Eli Zaretskii
2020-09-25 11:34 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-23 22:59 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-25 18:31 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-23 18:33 ` Stefan Monnier
2020-09-23 18:47 ` Eli Zaretskii
2020-09-23 23:18 ` Stefan Monnier
2020-09-24 14:34 ` Eli Zaretskii
2020-09-24 16:44 ` Stefan Monnier
2020-09-24 16:59 ` Eli Zaretskii
2020-09-27 21:59 ` Stefan Monnier
2020-09-28 6:20 ` Eli Zaretskii
2020-09-28 13:30 ` Stefan Monnier
2020-09-28 13:44 ` Eli Zaretskii
2020-09-28 16:58 ` Stefan Monnier
2020-10-02 15:40 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-10-02 16:08 ` Stefan Monnier
2020-10-02 16:11 ` Eli Zaretskii
2020-10-02 16:25 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-10-02 19:30 ` Eli Zaretskii
2020-10-02 21:49 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-29 14:02 ` Lars Ingebrigtsen
2020-09-23 19:46 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-23 20:00 ` Stefan Monnier
2020-09-23 22:47 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-23 23:20 ` Stefan Monnier
2020-09-23 23:26 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-24 2:07 ` Stefan Monnier
2020-09-24 7:45 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-24 16:26 ` Stefan Monnier
2020-09-24 8:06 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-24 14:43 ` Eli Zaretskii
2020-09-24 14:52 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-24 15:20 ` Eli Zaretskii
2020-09-24 14:26 ` Eli Zaretskii
2020-09-24 14:20 ` Eli Zaretskii
2020-09-24 14:27 ` Gregory Heytings via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-24 16:40 ` Stefan Monnier
2020-09-24 16:54 ` Eli Zaretskii
2020-09-27 16:11 ` Eli Zaretskii
2020-09-27 21:52 ` Stefan Monnier
2020-09-28 6:10 ` Eli Zaretskii
2020-09-28 13:24 ` Stefan Monnier
2020-09-28 13:42 ` Eli Zaretskii
2020-09-28 16:56 ` Stefan Monnier
[not found] <<alpine.NEB.2.22.394.2009222215560453.32542@sdf.lonestar.org>
[not found] ` <<jwvwo0ktlge.fsf-monnier+emacs@gnu.org>
[not found] ` <<alpine.NEB.2.22.394.2009232116430453.29439@sdf.lonestar.org>
[not found] ` <<834knnuugm.fsf@gnu.org>
[not found] ` <<jwvimc3p2a0.fsf-monnier+emacs@gnu.org>
[not found] ` <<83h7rnt8s3.fsf@gnu.org>
[not found] ` <<833633nqru.fsf@gnu.org>
[not found] ` <<jwvwo0e6gcb.fsf-monnier+emacs@gnu.org>
[not found] ` <<83r1qmmnxu.fsf@gnu.org>
2020-09-28 15:53 ` 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=alpine.NEB.2.22.394.2009222215560453.32542@sdf.lonestar.org \
--to=bug-gnu-emacs@gnu.org \
--cc=43572@debbugs.gnu.org \
--cc=ghe@sdf.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).