all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Jean Louis <bugs@gnu.support>
To: Ergus <spacibba@aol.com>
Cc: emacs-devel@gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>,
	Drew Adams <drew.adams@oracle.com>, Juri Linkov <juri@linkov.net>
Subject: Re: feature/completions-highlight-modifications e3c5b99 3/6: Add completions-highlight-mode initial implementation.
Date: Mon, 23 Nov 2020 17:13:54 +0300	[thread overview]
Message-ID: <X7vDopGOT4KZ1dyr@protected.rcdrun.com> (raw)
In-Reply-To: <20201123114620.6htiapgjp4oykvib@Ergus>

* Ergus <spacibba@aol.com> [2020-11-23 14:58]:
> IMO icomplete (and ido/ivy/helm/etc) are more invasive than this mode
> (as I conceived it initially at least) because they diverged much more
> from the *Completions* way to do and the <tab> philosophy.

TAB philosophy is for line based completions. Anything else need not
use TAB. Ivy is not based on TAB it is based on visual selection.

Helm is specifically not based on TAB and information about TAB can
be found on Helm Wiki.  

Emacs Helm Wiki
https://github.com/emacs-helm/helm/wiki

> In case you really think that nothing of this may become default then I
> prefer to add this code as a package to elpa instead; to not
> overload

Please give me reference that I can try that package to see how well
it fits in my needs.

> the base code with potentially useless/unknown modes that nobody will
> find useful/discover (once a user is capable to configure their init.el
> they will go for icomplete/ido/fido/ivy/helm instead of this).

For your research:

icomplete/ido/fido are built-in completions that I never use, simply
never. In fact I find them dangerous as unclear usage and bad design
(personal view and case of course) can easily lose files or complete
something else what is not meant to be.

ivy is in GNU ELPA and that is great, I am using ivy to visually
locate specific sets in the database or in database editing functions.

helm I use also for database work where visual selections and
filtering is necessary.

For switch to buffer I do use often either ivy or helm, it does not
matter.

But majority of my time I do not use those non built-in
completion. So majority of the time I am not using completions as the
Emacs built-in completion is equally fast, more precise and less
confusing!

If I would count number of keys I have to press in ivy to complete to
specific directory I think it is even more than necessary, same for
helm.

> I think very few old users use the default completions system these days
> and it gives a terrible first impression to new comers and make emacs
> feel too "vintage".

I do not share that idea, quite contrary I find Emacs built-in
standard completion very fine and pretty fast feature. When you are
familiar with it, it becomes easy. To users in my group so far I do
not even recommend anything else but the built-in.

Often I switch from one buffer to other, it is trivial to come back by
using built-in completion.

There are cases where visual completion really helps, but it does not
necessarily make things faster!

> I even considered to set an overlay but maybe this is something must be
> properly fixed (if it is an issue of course)

Any completion shall work well in console mode.

Please send me that package that I try it out.
Thank you.

Jean



  reply	other threads:[~2020-11-23 14:13 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20201115023629.19537.77471@vcs0.savannah.gnu.org>
     [not found] ` <20201115023631.C78AB20A27@vcs0.savannah.gnu.org>
2020-11-15 18:41   ` feature/completions-highlight-modifications e3c5b99 3/6: Add completions-highlight-mode initial implementation Stefan Monnier
2020-11-15 22:49     ` Ergus
2020-11-15 23:32       ` Stefan Monnier
2020-11-16  3:37         ` Ergus
2020-11-16  3:56           ` Stefan Monnier
2020-11-16  5:40             ` Drew Adams
2020-11-16  7:39             ` Ergus
2020-11-16  5:38           ` Drew Adams
2020-11-16  8:54             ` Juri Linkov
2020-11-16 10:27               ` Ergus
2020-11-16 20:23                 ` Juri Linkov
2020-11-16 21:16                   ` Drew Adams
2020-11-17  0:46                   ` Ergus
2020-11-17 20:02                     ` Juri Linkov
2020-11-17 20:52                       ` Drew Adams
2020-11-18 19:43                 ` Juri Linkov
2020-11-18 22:45                   ` Drew Adams
2020-11-19  3:25                   ` Ergus
2020-11-19  7:45                     ` Juri Linkov
2020-11-19 10:50                       ` Ergus
2020-11-20  9:32                         ` Juri Linkov
     [not found]                           ` <20201120145248.wmbv2zgbvs7bg25i@Ergus>
2020-11-21 19:30                             ` Juri Linkov
2020-11-22 13:28                               ` Ergus
2020-11-22 20:03                                 ` Juri Linkov
2020-11-22 23:09                               ` Ergus
2020-11-23  9:14                                 ` Juri Linkov
2020-11-23 11:46                                   ` Ergus
2020-11-23 14:13                                     ` Jean Louis [this message]
2020-11-23 19:12                                       ` Eli Zaretskii
2020-11-23 19:44                                         ` Jean Louis
2020-11-23 20:54                                     ` Dmitry Gutov
2020-11-23 23:27                                       ` Ergus via Emacs development discussions.
2020-12-10  1:16                                         ` Dmitry Gutov
2020-12-10  8:23                                           ` Juri Linkov
2020-11-25  8:49                                     ` Juri Linkov
2020-11-20 14:24                         ` Stefan Monnier
     [not found]                           ` <20201120144940.p55brblxpuowslag@Ergus>
2020-11-20 15:15                             ` Stefan Monnier
2020-11-16 16:03               ` Drew Adams
2020-11-16 20:28                 ` Juri Linkov
2020-11-16 21:31                   ` Drew Adams
2020-11-18 19:30                   ` Juri Linkov

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=X7vDopGOT4KZ1dyr@protected.rcdrun.com \
    --to=bugs@gnu.support \
    --cc=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=juri@linkov.net \
    --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 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.