From: Eli Zaretskii <eliz@gnu.org>
To: Andrii Kolomoiets <andreyk.mad@gmail.com>
Cc: spacibba@aol.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org
Subject: Re: [PATCH] Support "\n" in icomplete-separator
Date: Fri, 13 Nov 2020 10:39:15 +0200 [thread overview]
Message-ID: <835z69y7kc.fsf@gnu.org> (raw)
In-Reply-To: <m2v9eaxk7m.fsf@gmail.com> (message from Andrii Kolomoiets on Fri, 13 Nov 2020 00:51:25 +0200)
> From: Andrii Kolomoiets <andreyk.mad@gmail.com>
> Cc: spacibba@aol.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca
> Date: Fri, 13 Nov 2020 00:51:25 +0200
>
> > First, the overlay text is not just a "hint": sometimes it is very
> > important to let you know what to type next. For example, the list of
> > files in a large directory that are completion candidates is very
> > important to see, unless you know in advance what file you want.
> > Moreover, in some cases those "hints" are the _only_ way of knowing
> > what inputs are acceptable:
>
> Can you please show me the example of such usage in the default
> configuration?
emacs -Q
M-x icomplete-mode RET
C-x C-f
> As I can see, Emacs by default doesn't show any hints in the
> minibuffer while reading user input.
We are not talking about the default completion in this thread, we are
talking about icomplete-mode and its ilk. They work differently, and
in particular do show completion candidates automatically in the
minibuffer.
> Even with the icomplete-mode enabled, possible completions are not
> visible by default
See the trivial example of the contrary above.
> > Send this email message by: {Mailclient, Smtp, XDG-email}
> > - - -
> >
> > Without seeing the possible answers, what are your chances of knowing
> > what to type?
>
> Chances are pretty good: I'll press TAB to see the *Completions* buffer.
Pressing TAB seems to be against the philosophy of icomplete, ivy, and
similar features, at least AFAIU: they display the candidates without
any prior request by the user.
> > OTOH, sometimes the prompt is not important: when you yourself invoke
> > the command that prompts. For example, if you type "C-x C-f", how
> > important is it for you to see the "Find file" prompt? Probably not
> > too important.
>
> Next to "C-x C-f" is "C-x C-d", so if you accidentally hit the "d"
> instead of the "f", the prompt is the only one who can tell you why no
> files are showed in the completion hints. For me the prompt is
> important. Sometimes I hit "C-x v d" instead of "C-x C-f" and try to
> complete filename to find.
You are just confirming the point I want to make: that sometimes we
want/need to see the beginning, and sometimes we don't. IOW, that
there are examples from either class doesn't mean one of the two
classes is invalid or not interesting.
> > The strategy Emacs uses to display stuff in the mini-window is shared
> > by both minibuffer and echo-area display -- in the latter case your
> > proposal that distinguishes between the prompt, the rest of the text,
> > and the overlay at the end, will not necessarily make sense.
>
> Oh, in this case let's try even simpler approach: show as much text
> before point as possible.
What is "this case"? If "this case" is limited to echo-area display,
then it cannot be shared with minibuffer display. If you mean both
use cases, then "displaying as much as possible before point" will
yield sub-optimal results for minibuffer input, when some text is
displayed after point, whether as an aoverlay string or not.
> > But those uses don't invalidate the design assumptions, they just
> > demand support for very different use cases.
>
> Then I have a question about the display strategy: why is the tail of
> the message is more important than the head?
It is based on heuristic, and assumes the default values of the
variables. It also assumes that the mini-window is not used to show
too much stuff.
> For example, evaluate this buffer:
>
> (setq max-mini-window-height 1)
> (set-frame-width nil 77)
>
> Now move point to the "max-mini-window-height" and wait to eldoc message
> to come up.
> What I see in the echo-area is "fer and the echo area).".
Yes, with radical enough customizations of the defaults, the results
could be disastrous. However, the above could arguably be seen as a
bug in ElDoc: it should arrange for the mini-window to be configured
properly to show the info, or perhaps use the mode line in this case.
> > The conclusion, IMO, is that the application should tell the display
> > engine how it wants to display the stuff in the mini-window in the
> > "unusual" cases, where the default strategy produces sub-optimal
> > results.
>
> I see many applications are trying their best to fit the text into the
> miniwindow. Can the display strategy be changed to display the
> beginning of the text by default?
We can do that, but I don't think it would be TRT, because the current
strategy does work in many use cases. I thin a better way is to let
applications control this aspect of the behavior, because we will
never be able to find a solution that always works, what with all the
different settings and kinds of display in the mini-window.
next prev parent reply other threads:[~2020-11-13 8:39 UTC|newest]
Thread overview: 126+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-05 23:10 [PATCH] Support "\n" in icomplete-separator Andrii Kolomoiets
2020-11-05 23:29 ` Stefan Monnier
2020-11-06 0:04 ` Ergus
2020-11-06 2:44 ` Stefan Monnier
2020-11-06 8:42 ` Gregory Heytings via Emacs development discussions.
2020-11-06 10:26 ` Andrii Kolomoiets
2020-11-05 23:57 ` Ergus
2020-11-06 8:43 ` Gregory Heytings via Emacs development discussions.
2020-11-06 12:36 ` Andrii Kolomoiets
2020-11-06 15:15 ` Ergus
2020-11-08 20:14 ` Andrii Kolomoiets
2020-11-08 20:30 ` Gregory Heytings via Emacs development discussions.
2020-11-08 20:36 ` Andrii Kolomoiets
2020-11-09 3:28 ` Eli Zaretskii
2020-11-09 21:04 ` Andrii Kolomoiets
2020-11-10 15:13 ` Eli Zaretskii
2020-11-10 17:18 ` Andrii Kolomoiets
2020-11-10 18:18 ` Gregory Heytings via Emacs development discussions.
2020-11-11 9:41 ` Andrii Kolomoiets
2020-11-10 18:23 ` Eli Zaretskii
2020-11-10 19:17 ` Gregory Heytings via Emacs development discussions.
2020-11-10 19:27 ` Eli Zaretskii
2020-11-10 20:00 ` Gregory Heytings via Emacs development discussions.
2020-11-10 21:09 ` Andrii Kolomoiets
2020-11-11 8:27 ` martin rudalics
2020-11-11 9:07 ` Gregory Heytings via Emacs development discussions.
2020-11-11 15:57 ` Jean Louis
2020-11-11 9:38 ` Andrii Kolomoiets
2020-11-11 10:01 ` martin rudalics
2020-11-11 10:21 ` Gregory Heytings via Emacs development discussions.
2020-11-11 10:53 ` martin rudalics
2020-11-11 11:22 ` Gregory Heytings via Emacs development discussions.
2020-11-11 15:49 ` martin rudalics
2020-11-11 15:57 ` Eli Zaretskii
2020-11-11 16:16 ` Jean Louis
2020-11-11 17:06 ` martin rudalics
2020-11-11 17:28 ` Gregory Heytings via Emacs development discussions.
2020-11-11 16:05 ` Gregory Heytings via Emacs development discussions.
2020-11-11 17:06 ` martin rudalics
2020-11-11 17:26 ` Stefan Monnier
2020-11-11 17:37 ` Gregory Heytings via Emacs development discussions.
2020-11-11 15:32 ` Jean Louis
2020-11-11 15:26 ` Jean Louis
2020-11-11 16:06 ` Eli Zaretskii
2020-11-11 17:12 ` Gregory Heytings via Emacs development discussions.
2020-11-11 17:19 ` Alfred M. Szmidt
2020-11-11 17:44 ` Gregory Heytings via Emacs development discussions.
2020-11-11 17:50 ` Alfred M. Szmidt
2020-11-11 18:14 ` Eli Zaretskii
2020-11-11 18:09 ` Eli Zaretskii
2020-11-11 18:39 ` Gregory Heytings via Emacs development discussions.
2020-11-11 20:21 ` Eli Zaretskii
2020-11-11 20:37 ` Gregory Heytings via Emacs development discussions.
2020-11-11 21:55 ` Ergus
2020-11-11 22:26 ` Jean Louis
2020-11-11 22:59 ` Stefan Monnier
2020-11-12 3:28 ` Eli Zaretskii
2020-11-12 8:50 ` Gregory Heytings via Emacs development discussions.
2020-11-12 9:13 ` on helm substantial differences - " Jean Louis
2020-11-12 9:20 ` Gregory Heytings via Emacs development discussions.
2020-11-12 10:25 ` Jean Louis
2020-11-12 10:54 ` Gregory Heytings via Emacs development discussions.
2020-11-12 11:33 ` Jean Louis
2020-11-12 14:40 ` Gregory Heytings via Emacs development discussions.
2020-11-12 17:46 ` Jean Louis
2020-11-12 14:41 ` Eli Zaretskii
2020-11-12 17:49 ` Jean Louis
2020-11-12 17:58 ` Eli Zaretskii
2020-11-12 14:36 ` Eli Zaretskii
2020-11-12 15:05 ` Gregory Heytings via Emacs development discussions.
2020-11-12 15:36 ` Eli Zaretskii
2020-11-12 16:10 ` Gregory Heytings via Emacs development discussions.
2020-11-12 17:50 ` Eli Zaretskii
2020-11-13 12:40 ` Gregory Heytings via Emacs development discussions.
2020-11-13 12:59 ` Eli Zaretskii
2020-11-13 13:36 ` Gregory Heytings via Emacs development discussions.
2020-11-13 13:52 ` Eli Zaretskii
2020-11-13 15:09 ` Stephen Berman
2020-11-13 16:05 ` Eli Zaretskii
2020-11-13 17:31 ` Stephen Berman
2020-11-16 10:24 ` Gregory Heytings via Emacs development discussions.
2020-11-16 17:44 ` Eli Zaretskii
2020-11-17 11:51 ` Gregory Heytings via Emacs development discussions.
2020-11-12 7:58 ` martin rudalics
2020-11-12 8:52 ` Gregory Heytings via Emacs development discussions.
2020-11-12 14:37 ` Eli Zaretskii
2020-11-12 12:39 ` Dmitry Gutov
2020-11-12 19:31 ` Howard Melman
2020-11-12 20:02 ` ivy-posframe review - " Jean Louis
2020-11-11 14:09 ` Jean Louis
2020-11-11 15:51 ` Eli Zaretskii
2020-11-11 16:05 ` Jean Louis
2020-11-11 18:52 ` Drew Adams
2020-11-11 19:10 ` martin rudalics
2020-11-11 19:49 ` Drew Adams
2020-11-12 7:58 ` martin rudalics
2020-11-11 19:51 ` Drew Adams
2020-11-11 16:30 ` Eli Zaretskii
2020-11-12 22:51 ` Andrii Kolomoiets
2020-11-13 8:39 ` Eli Zaretskii [this message]
2020-11-13 12:56 ` Gregory Heytings via Emacs development discussions.
2020-11-13 13:02 ` Eli Zaretskii
2020-11-13 13:44 ` Gregory Heytings via Emacs development discussions.
2020-11-13 13:55 ` Eli Zaretskii
2020-11-16 10:25 ` Gregory Heytings via Emacs development discussions.
2020-11-16 17:40 ` Eli Zaretskii
2020-11-16 17:41 ` Stefan Monnier
2020-11-16 18:24 ` Eli Zaretskii
2020-11-17 11:51 ` Gregory Heytings via Emacs development discussions.
2020-11-17 14:05 ` Stefan Monnier
2020-11-13 19:27 ` Andrii Kolomoiets
2020-11-17 8:59 ` Gregory Heytings via Emacs development discussions.
2020-11-13 20:18 ` Andrii Kolomoiets
2020-11-14 6:17 ` Ergus
2020-11-14 20:36 ` Andrii Kolomoiets
2020-11-15 2:39 ` Ergus
2020-11-15 19:32 ` Andrii Kolomoiets
2020-11-10 20:01 ` Stefan Monnier
2020-11-06 5:52 ` Jean Louis
2020-11-06 12:40 ` Andrii Kolomoiets
2020-11-06 12:59 ` Jean Louis
2020-11-08 20:28 ` Andrii Kolomoiets
2020-11-08 20:50 ` Jean Louis
-- strict thread matches above, loose matches on Subject: below --
2020-11-06 16:30 Drew Adams
[not found] <<m2a6vv8ko3.fsf@gmail.com>
[not found] ` <<20201105235735.oxouuek66ehu5o45@Ergus>
[not found] ` <<m2y2je7jcx.fsf@gmail.com>
[not found] ` <<20201106151541.dpgep7borlja25su@Ergus>
[not found] ` <<m2d00n7gj4.fsf@gmail.com>
[not found] ` <<837dqv5huk.fsf@gnu.org>
[not found] ` <<m24klys0n2.fsf@gmail.com>
[not found] ` <<83mtzp2qj0.fsf@gnu.org>
[not found] ` <<m2imad6sh1.fsf@gmail.com>
[not found] ` <<83r1p11369.fsf@gnu.org>
[not found] ` <<m2a6vo7wcw.fsf@gmail.com>
[not found] ` <<ca240036-8493-968d-2204-620f430334b9@gmx.at>
[not found] ` <<m2sg9g5j2p.fsf@gmail.com>
[not found] ` <<fe70158f-d55a-010a-74ba-2f81d1bb7663@gmx.at>
[not found] ` <<837dqr27zs.fsf@gnu.org>
2020-11-11 19:03 ` Drew Adams
[not found] ` <<alpine.NEB.2.22.394.2011111803220453.17489@sdf.lonestar.org>
[not found] ` <<83361f22ah.fsf@gnu.org>
[not found] ` <<alpine.NEB.2.22.394.2011111926450453.27530@sdf.lonestar.org>
[not found] ` <<83sg9fzlto.fsf@gnu.org>
[not found] ` <<alpine.NEB.2.22.394.2011112128400453.4149@sdf.lonestar.org>
[not found] ` <<83r1ozz22j.fsf@gnu.org>
[not found] ` <<alpine.NEB.2.22.394.2011120932160453.28737@sdf.lonestar.org>
[not found] ` <<83d00izloj.fsf@gnu.org>
[not found] ` <<alpine.NEB.2.22.394.2011121544550453.26984@sdf.lonestar.org>
[not found] ` <<83361ezix2.fsf@gnu.org>
2020-11-12 17:42 ` 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=835z69y7kc.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=andreyk.mad@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=spacibba@aol.com \
/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).