From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Gregory Heytings <ghe@sdf.org>
Cc: emacs-devel@gnu.org
Subject: Re: A solution to display completion candidates after point in a minibuffer
Date: Fri, 02 Oct 2020 15:24:00 -0400 [thread overview]
Message-ID: <jwvv9fsea10.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <alpine.NEB.2.22.394.2010021839550453.4600@sdf.lonestar.org> (Gregory Heytings's message of "Fri, 02 Oct 2020 17:17:03 +0000")
>> I think you should better define the problem you're trying to solve.
> This problem is known to those who have been working on workarounds to
> circumvent it: displaying completion candidates in the minibuffer after
> prompt, without hiding the prompt.
This description is not helpful because it is too vague.
E.g. it's not clear what you mean by "prompt".
is it really just the `minibuffer-prompt`?
If so, why do you specifically care about the prompt?
I usually find it more important to see the candidates than the prompt
(the prompt is important at the beginning, before you start writing
your answer, but after that it loses a lot of its importance).
Also, what do you mean by "without hiding the prompt". There are cases
where there's no other option than to hide the prompt, so which cases
are you specifically interested in? Also, what if some of the prompt is
visible but not all, is that a problem you're concerned with, or not?
> (let (w bd)
> (setq w 60)
> (setq bd (concat (temporary-file-directory) (make-string w ?a) "/"))
AKA
(let ((w 60)
(bd (expand-file-name (make-string w ?a) (temporary-file-directory))))
> (dolist (d '("a" "b" "c" "d" "e")) (make-directory (concat bd d) t))
> (setq default-directory bd)
> (set-frame-height nil 20)
> (set-frame-width nil (+ (length bd) 10))
> (icomplete-mode)
> (setq icomplete-separator "\n")
> (call-interactively 'insert-file))
[ FWIW, I just tried it in my local Emacs where I replaced the ad-hoc
`resize_mini_window` scrolling with the use of `scroll-conservatively`,
and I get the behavior that you seem to prefer. ]
[ Side note: I had sent a better recipe for that using a repetition of
`foo/..` so as to avoid having to create any new files or
directories. ]
Thanks. Indeed, this recipe shows a problem where the prompt is not
displayed at all right at the beginning of the interaction, so the
unwary user won't get to see what the prompt says without extra effort.
At the same time, the text that is displayed (i.e. without the prompt
but with one more line of candidates) is arguably a better choice when
the user knows what the prompt says (as would be the case for me
when I call `insert-file`).
So while I would tend to agree that showing the first line would
probably be better it's debatable. At least, I don't think this
minor difference warrants the kind of code you're proposing.
>> Also this has some problematic aspects:
>> - it focuses all its energy on showing the text before point, which is
>> often the right choice, but not always.
> Indeed, that's not always the right choice, which is why this solution
> does this if, and only if, the buffer-local variable
> start-display-at-beginning-of-minibuffer has been set, in
> minibuffer-setup-hook.
But it depends on other factors than "displaying the minibuffer".
It can vary over the lifetime of the very same minibuffer.
>> - There's of course a risk of inf-loop if (set-window-start nil (1- end))
>> leads to (pos-visible-in-window-p end nil t) returning nil. How/when could
>> this happen, I'm not completely sure, but it doesn't seem impossible.
> In practice it's not possible, unless the width of the Emacs frame is so
> small that setting window-start near point (at point-1) would still leave
> point invisible.
It doesn't seem impossible even with a wide window. I think risky
situations would include cases where point is right after a newline,
and/or where tall glyphs are involved (either via face settings, or
images, ...).
>> Now, I know experience shows that it does work at least in some cases, but
>> if so I think the code should come with a clear comment explaining why
>> that warning doesn't apply here (and maybe the corresponding C code should
>> also get a comment explaining the properties/invariants/berhaviors that it
>> preserves and that make such uses work, so we don't break it by accident).
> This I cannot do, alas, I'm not an expert. I tried this solution
> extensively, on different Emacs versions. Perhaps there are cases where it
> does not work, but I doubt it.
I'd be uneasy using such code without some vague understanding about
*why* it works.
>> Actually, it seems like your code would allow to do that by running some
>> icomplete code at the end of your `set-window-start-at-begin` to truncate
>> the overlay's text according to where the text is truncated.
> That's possible, thanks for the idea, I'll try to see if this can be
> done. But I'm not sure, because modifying the contents of the buffer
> would mean that redisplay would be called again, which would again set
> window-start to another value.
Which is the kind of reason where we'd benefit from knowing *why* it works.
>>> 7. (add-hook 'post-command-hook
>>> 'start-display-at-beginning-of-minibuffer) is necessary only with
>>> variable width faces, but it is does not harm to use it with fixed
>>> width faces.
>> I don't understand why the kind of face in use would make a difference
>> w.r.t needing to use `post-command-hook`.
> I don't understand it either, alas. An example, which does not work without
> start-display-at-beginning-of-minibuffer in post-command-hook with Emacs
> 26.3 (but works without it with Emacs 27.1):
Thanks for the example. I think this highlights the need to better
understand how/why this works.
Stefan
next prev parent reply other threads:[~2020-10-02 19:24 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-02 15:36 A solution to display completion candidates after point in a minibuffer Gregory Heytings via Emacs development discussions.
2020-10-02 16:04 ` Eli Zaretskii
2020-10-02 16:14 ` Gregory Heytings via Emacs development discussions.
2020-10-02 16:20 ` Eli Zaretskii
2020-10-02 16:32 ` Stefan Monnier
2020-10-02 17:17 ` Gregory Heytings via Emacs development discussions.
2020-10-02 19:24 ` Stefan Monnier [this message]
2020-10-02 20:18 ` Drew Adams
2020-10-02 21:30 ` Gregory Heytings via Emacs development discussions.
2020-10-02 22:44 ` Stefan Monnier
2020-10-02 23:11 ` Gregory Heytings via Emacs development discussions.
2020-10-03 0:10 ` Stefan Monnier
2020-10-03 6:59 ` Gregory Heytings via Emacs development discussions.
2020-10-03 9:04 ` Eli Zaretskii
2020-10-04 16:11 ` Gregory Heytings via Emacs development discussions.
2020-10-04 16:21 ` Eli Zaretskii
2020-10-04 16:52 ` Gregory Heytings via Emacs development discussions.
2020-10-04 17:00 ` Eli Zaretskii
2020-10-03 8:25 ` Eli Zaretskii
2020-10-03 8:07 ` Eli Zaretskii
2020-10-02 22:40 ` Gregory Heytings via Emacs development discussions.
2020-10-03 12:31 ` Gregory Heytings via Emacs development discussions.
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvv9fsea10.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=emacs-devel@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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.