emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: on helm substantial differences - Re: [PATCH] Support "\n" in icompl


From: Jean Louis
Subject: Re: on helm substantial differences - Re: [PATCH] Support "\n" in icomplete-separator
Date: Thu, 12 Nov 2020 14:33:37 +0300
User-agent: Mutt/2.0 (3d08634) (2020-11-07)

* 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: 01-split-window-before-completion.png
Description: PNG image

Attachment: 02-helm-replaces-bottom-split-window-correctly.png
Description: PNG image

Attachment: 03-ivy-disturbes-all-screen-by-default.png
Description: PNG image

Attachment: 04-ivy-with-outside-function-enlarges-bottom-window.png
Description: PNG image

Attachment: 05-selectrum-after-split-window-behaving-better.png
Description: PNG image


reply via email to

[Prev in Thread] Current Thread [Next in Thread]