unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Arthur Miller <arthur.miller@live.com>
Cc: Howard Melman <hmelman@gmail.com>, emacs-devel@gnu.org
Subject: key completion   [was: transient]
Date: Sun, 24 May 2020 12:19:14 -0700 (PDT)	[thread overview]
Message-ID: <d84160a7-3411-4487-9bc6-2498a9645536@default> (raw)

> I haven't used Icicles yet, but seen this list, maybe I
> should give it a try and see if I can use it instead of
> which-key.

To be clear, my reason for posting that info was to
show other possibilities, not to solicit Icicles
users.  The features I showed there are in some ways
similar to what you get with things like `which-key',
but they're also different.  Difference always means
pros & cons.

Some of the UI/completion features introduced by
Icicles have since been adopted in other completion
frameworks (e.g. Helm, Ivy, Icomplete).  There are
many others that have not been taken up.

I use Icicles all the time, but from the beginning
I've considered it largely as a sandbox of related
features that can serve as food for thought.

Icicles features are related in that they feed off
of each other; they work well together.

But could something like Icicles key completion be
taken out of Icicles?  Absolutely, with some loss
of functionality.

Icicles key completion doesn't depend on the rest
of Icicles for its most basic behavior.  But it
becomes more useful in concert with other Icicles
features (different sort orders, progressive and
apropos completion, candidate highlighting etc.).

___

I've done that now - just posted library `keysee.el'.
It provides some of what Icicles key completion
provides.  But there's no incremental completion,
progressive completion, etc.  No sorting or cycling
of candidates, etc.  Anyway, you can try it:

Description: https://www.emacswiki.org/emacs/KeySee

Code: https://www.emacswiki.org/emacs/keysee.el

> Can Icicles be used without any additional learning
> and as easy as which-key? Which-key is kind-of
> "just works", one installs it and it does what it
> does without additional effort on user side. Is
> "automatic" feature of Icicles in same manner?

Icicles has a lot more to it than key completion.
And out of the box, it (i.e. minor mode `icy-mode')
will change your Emacs experience.  That might not
be what you want.  I wouldn't want to encourage it
just as a supplement or replacement for `which-key'.

If you want to try Icicles key completion, to play
with it, yes, it's easy.  You'll need to download
the Icicles files and put them in your `load-path',
then `(require 'icicles)' and turn on `icy-mode'.

To get automatic key completion, turn on minor mode
`icicle-auto-complete-keys-mode'.  (You can still
use key completion on demand (`S-TAB'), even at
top level.)

One of the things I think Icicles helps most with,
in general, is "asking Emacs".  Key completion is
one example.  I believe there's lots _more_ room
for improving Emacs to help users "Ask Emacs" than
anything I've done.  Again, I hope that some of
the things I've done as experiments (some of which
may be silly or crazy) might suggest other ways
to make Emacs help you ask Emacs.

FWIW, key completion was definitely one of the
things I initially thought was crazy, but which I
changed my mind about.  (But no, it's not really
a replacement for `which-key', `guide-key', etc.,
which are fine for what they offer.)
____

> [Dired+] What spontaneously to look usefull is
> marking/toggeling/untoggling files per region only.
> That seems like a usefull feature. Maybe you should
> try to get that part into standard Dired?

I've offered all of my code, or any parts of it,
many times.  And I've also tried to get specific
parts added, usually unsuccessfully.  I don't
spend time now fighting that.  The code's there,
for anyone who might be interested.  And I do help
when someone wants help understanding etc.

Most of the things in a library like Dired+ are
easy to add to vanilla Emacs, I think.  If someone
sees something they want to add, and needs help
understanding it, I'm here.  I don't have the time
or will to try to push anything or convince or ...

I do typically speak up if I see some effort that's
related, to at least say what's available in one of
my libraries that might serve as food for thought
or a guide to one way to do something.



                 reply	other threads:[~2020-05-24 19:19 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=d84160a7-3411-4487-9bc6-2498a9645536@default \
    --to=drew.adams@oracle.com \
    --cc=arthur.miller@live.com \
    --cc=emacs-devel@gnu.org \
    --cc=hmelman@gmail.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).