From: Jean Louis <bugs@gnu.support>
To: Gregory Heytings <ghe@sdf.org>
Cc: spacibba@aol.com, andreyk.mad@gmail.com, emacs-devel@gnu.org,
rudalics@gmx.at, monnier@iro.umontreal.ca,
Eli Zaretskii <eliz@gnu.org>
Subject: Re: on helm substantial differences - Re: [PATCH] Support "\n" in icomplete-separator
Date: Thu, 12 Nov 2020 14:33:37 +0300 [thread overview]
Message-ID: <X60dkaBDiWMHp3Nu@protected.rcdrun.com> (raw)
In-Reply-To: <alpine.NEB.2.22.394.2011121148090453.7679@sdf.lonestar.org>
[-- Attachment #1: Type: text/plain, Size: 4171 bytes --]
* Gregory Heytings <ghe@sdf.org> [2020-11-12 13:54]:
>
> > > > > This is very subjective. I find the looks of the minibuffer
> > > > > with vertical completions very nice, and given the
> > > > > popularity of packages that implement that feature (Helm and
> > > > > Ivy) I'm sure I'm not alone. And, FWIW, I would very much
> > > > > dislike a "combo box like UI" to replace this.
> > > >
> > > > Helm does not offer minibuffer with vertical completions.
> > >
> > > I know. But for the purpose of _this_ discussion (prettyness of a
> > > vertical presentation of completion candidates by Emacs compared to
> > > other software) what it does is the same.
> >
> > icomplete vertical completion is not same to helm completion.
> >
> > Maybe you did not see or did not observe the difference which is to me
> > very substantial.
> >
>
> I'll say it again: I know that they are different. But for the purpose of
> _this_ discussion, which is about the _visual prettyness_ of a vertical
> presentation of completion candidates compared to other software (and
> therefore _not_ about what you can _do_ / how you can _interact_ with that
> completion candidates list). And from that viewpoint Helm and Ivy are
> similar: both display completion candidates vertically at the bottom of the
> frame. Or at least I do not see how one could say that Helm is _visually
> pretty_ and Ivy is not (or the other way around).
You may see that if you compare various functions by observing it and
turning off the ideas or preconceptions that you are trained
to. Forget everything, then observe it again.
You may have artists as friends, just find one and ask him what is
difference. Let people observe it for 5 minutes and find differences.
To help in observation there are 5 pictures attached in this email.
Initial condition is picture 01-split-window-before-completion.png
where it is shown with the frame split in two windows. I am searching
in the top window and pressing / to enter into completion feature.
When helm-mode is enabled:
- bottom window is used for completion
- windows do not get disturbed, none is enlarging or disturbing me as
user
- minibuffer stays mini, does not expand
Compare that to following picture:
03-ivy-disturbes-all-screen-by-default.png when I use default ivy-mode:
- minibuffer expands disturbing all the screen
- bottom split window is shown but is useless. If it is to be
disturbed then don't show it to me at all. I think but I may be
wrong, that icomplete works this way last time I tested it.
- minibuffer is not any more there! How should I teach my stuff that
they have certain control with minibuffer which is normally at
bottom. I teach my staff by sending them Tutorial to do and info
files to read.
- It did expand but it expands too much. It disturbs even the initial
condition of how windows were split. So it is minimizing my top
window for the sake of completion. Do I really want that? No. All
these commentaries are not to make anybody bad, they are for
thinking and observations when designing these completions.
Better behavior for ivy is on picture:
04-ivy-with-outside-function-enlarges-bottom-window.png
When I use outside function which is not yet in ivy, then at least:
- I get more visibility on the top window
- bottom window is not even visible, I am fine with it so far as I
complete in the upper window. That bottom window could be very
necessary for completion is also true but I prefer having cleaner
screen rather then messed up screen.
- minibuffer remains mini with this outside enhancement to ivy. This
way I do not think that jumping minibuffer represents the mode line
for the top window. That really creates confusions.
On picture: 05-selectrum-after-split-window-behaving-better.png I am
also showing Selectrum package that also behaves badly in relation to
interface. After some talk with developers one at least made
enhancements in a separate branch, so Selectrum now behaves with such
non-official enhancement as good as helm:
- minibuffer remains mini
- bottom window is replaced temporary with selections
- window sizes do not get disturbed
[-- Attachment #2: 01-split-window-before-completion.png --]
[-- Type: image/png, Size: 120713 bytes --]
[-- Attachment #3: 02-helm-replaces-bottom-split-window-correctly.png --]
[-- Type: image/png, Size: 110380 bytes --]
[-- Attachment #4: 03-ivy-disturbes-all-screen-by-default.png --]
[-- Type: image/png, Size: 107927 bytes --]
[-- Attachment #5: 04-ivy-with-outside-function-enlarges-bottom-window.png --]
[-- Type: image/png, Size: 116076 bytes --]
[-- Attachment #6: 05-selectrum-after-split-window-behaving-better.png --]
[-- Type: image/png, Size: 92691 bytes --]
next prev parent reply other threads:[~2020-11-12 11:33 UTC|newest]
Thread overview: 123+ 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 [this message]
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
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
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=X60dkaBDiWMHp3Nu@protected.rcdrun.com \
--to=bugs@gnu.support \
--cc=andreyk.mad@gmail.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=ghe@sdf.org \
--cc=monnier@iro.umontreal.ca \
--cc=rudalics@gmx.at \
--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).