unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Samuel Wales <samologist@gmail.com>
To: Drew Adams <drew.adams@oracle.com>
Cc: help-gnu-emacs@gnu.org, Christian Engels <s9chenge@stud.uni-saarland.de>
Subject: Re: What completion mechanisms are you using?
Date: Sun, 1 Feb 2009 15:43:09 -0700	[thread overview]
Message-ID: <20524da70902011443i1425ed8scaabc701c32c4417@mail.gmail.com> (raw)
In-Reply-To: <002501c984af$d8818580$0200a8c0@us.oracle.com>

I can't speak for the poster, but it seems like his q is similar to
mine a while back.

ido has a nearly perfect io for files and buffers (and lots of things
in org mode).  But it doesn't by default work with M-x (though there
is code for that) and the rare other things.

Therefore, since icicles seems so customizable, it's natural to wonder
whether you can easily make it emulate ido, or, if not, work only with
things that ido does not.  It sounds like the answers are "don't
bother to try because you'll just get frustrated" and "no".

Confirm?

Also, just out of curiosity (I won't be using icicles if it can't be
made to work like ido :)) does the completions buffer work for people
who set pop-up-windows to nil?

Thanks.

On Sun, Feb 1, 2009 at 13:58, Drew Adams <drew.adams@oracle.com> wrote:
>> > > > > ask you what extensions you are using and how they help you
>> > > > > to optimize your day to day work.
>> > > >
>> > > > I'm a big fan icicles. It adds completion for pretty much
>> > > > any minibuffer related activity you can think of (and
>> > > > then some).
>> > > >
>> > > > I still haven't come close to really utilizing it to it's full
>> > > > potential (but then, with emacs in general that is a rather
>> > > > normal state of affairs for me!)
>> > > >
>> > > > Features that I use often would include:
>> > > >  * Regex and Fuzzy matching.  These are great when I have a
>> > > >    general idea what something I'm looking for is named but not
>> > > >    exactly. Also good for exploring possibilities within a
>> > > >    subset of functionality.
>> > > >
>> > > >  * Saving completion lists to act as de facto file listings for
>> > > >    projects.
>> > > >
>> > > >  * Using it's completion to enhance the discoverability of emacs
>> > > >    commands for myself.
>> > >
>> > > At the moment i use ido and icomplete. But icicles seems
>> > > really nice for completion. The only problem i have is, that
>> > > it doesn't work well with ido.
>> >
>> > Icicles and Ido are incompatible. They use the minibuffer
>> > in different ways. Icicles stays closer to the vanilla Emacs
>> > behavior, extending it by using additional keys.
>> >
>> > > Why i want this weird setup is easy. I think ido is perfect
>> > > for files with the way it shows them to me on selecting and
>> > > the way you can browse through directories.
>> >
>> > You would need to be more specific for me to be helpful
>> > about this wrt Icicles. What do you mean by "shows them to me
>> > on selecting"?
>> >
>> > If you mean that the file is visited as soon as you type
>> > enough characters to get a match, then you can get similar
>> > behavior with Icicles (see links below).
>>
>> No, what i mean is the following behaviour. If i type C-x C-f
>> i get right away a list of possible matches in the minibuffer.
>
> OK, so you want to see the possibile completions immediately.
>
> To get that behavior with Icicles, customize option
> `icicle-show-Completions-initially-flag' to t. But in Icicles, like in vanilla
> Emacs, the candidates are shown in buffer *Completions*, not in the minibuffer.
> If you set the option to a non-nil, non-t value, then *Completions* is not
> displayed until you type or delete some input; otherwise, non-nil shows the
> candidates immediately.
>
> I know that some Icicles users prefer the show-initially behavior, but most do
> not. It's easy for an Icicles user to try the different behaviors in various
> contexts, to see which s?he prefers overall.
>
> One thing to keep in mind: Icicles completion is available in *every*
> minibuffer-completion context, not just for file and buffer names. What might
> seem like a good idea at first for file names or buffer names is not necessarily
> a great idea for other contexts also.
>
> Rather than customizing `icicle-show-Completions-initially-flag' to non-nil, it
> is more typical, for a particular context in which initial display of candidates
> makes sense, to temporarily bind the option to non-nil. That can be done to make
> use of *Completions* as a menu, for instance. (A special case is a
> multiple-choice menu, where you can choose more than one item or choose an item
> any number of times.)
>
>> This get more refined if i add letters.
>
> Such incremental completion is also standard behavior for Icicles. But you can
> toggle it at any time, using `C-#' in the minibuffer. It can be time-consuming
> or annoying in some contexts (e.g. zillions of candidates, such as all of the
> files in your file system).
>
> Besides toggling this, you can customize its behavior, using options
> `icicle-incremental-completion-flag', `icicle-incremental-completion-delay' and
> `icicle-incremental-completion-threshold'.
>
>> For example if i am in a directory with the files aa.txt aac.txt b.txt
>> after ido-find-file i get the following line in the minibuffer:
>> find file: ~/{aa.txt | aac.txt | b.txt}
>> If i now type a it looks like:
>> find file: ~/a[a]{aa.txt | aac.txt}
>> If i now hit Return i get aa.txt and if i hit right cursor it changes to
>> find file: ~/{aac.txt | b.txt | aa.txt}.
>
> Similarly, in Icicles.
>
> But Icicles uses regexp matching for this, by default. AFAIK, Ido uses substring
> matching here, which is a proper subset of regexp matching.
>
> If you want only substring matching in Icicles, you can customize option
> `icicle-regexp-quote-flag' to non-nil. That escapes any regexp special
> characters in your input. Or you can just use `C-`' in the minibuffer at any
> time, to toggle this option (hence toggle substring/regexp completion).
>
>> I hope this gets clearer.
>>
>> > > For example with ido you just have to hit Backspace to go one
>> > > directory up.
>> >
>> > Icicles is like vanilla Emacs wrt editing in the minibuffer:
>> > Backspace just back-spaces, etc. To go up a directory, you
>> > need to hit 3 keys, `M-k ..', instead of one. That's the same
>> > as vanilla Emacs - Icicles justs adds a `M-k' binding to clear
>> > the minibuffer.
>> >
>> > IOW, Icicles does not have separate editing and command
>> > modes in the minibuffer. Like vanilla Emacs, Icicles minibuffer
>> > interaction is not modal. Backspace is always an editing key.
>> >
>> > You could of course bind some key in the minibuffer keymaps
>> > to go up a directory.
>>
>> I didn't know that, thanks for the advice but binding a key
>> will not really help.
>> Again an example of ido's behaviour:
>> find file: a{ aa.txt | aac.txt | b.txt}
>> If i now hit Backspace i get
>> find file: /tmp/{ aa.txt | aac.txt | b.txt}
>> If i now hit backspace again i get
>> find file: /{ $list of files}
>>
>> Is this possible with a keybinding?
>
> That's already the same in Icicles - no need to change any key bindings. That's
> just incremental completion - see above.
>
> That simply shows the completion candidates that correspond to whatever is
> currently in the minibuffer. If the minibuffer has `/tmp/' as content, then the
> candidates are the files in directory `/tmp/'.
>
> Even vanilla Emacs works this way. But vanilla Emacs doesn't have incremental
> completion - you must hit TAB to see the completions of the new (edited)
> minibuffer input. (But as I mentioned, that's not always a drawback - sometimes
> it's an advantage to complete only on demand. It depends on the context.)
>
>> > > So has somebody a clue how i can setup icicles that it gets
>> > > used for everything except the things ido uses?
>> >
>> > As I said, their use of the minibuffer conflicts. This makes
>> > them incompatible - each tries to control the minibuffer UI.
>> > Icicles generally plays along with vanilla Emacs minibuffer
>> > bindings; Ido does not.
>> >
>> > That said, there are some Icicles options you can use to
>> > make some of the behavior more Ido-like. See:
>> > http://www.emacswiki.org/emacs/Icicles_-_Alternative_Libraries and
>> > http://www.emacswiki.org/emacs/Icicles_-_S-RET
>> >
>> > But overall, do not look to reproducing the Ido UI in Icicles.
>> > That's a bit like trying to reproduce vi-like behavior in Emacs:
>> > You can do it to some extent, but an Ido or VI diehard will
>> > likely be disappointed with the compromise.
>> >
>> > On the other hand, Icicles is compatible with Iswitchb,
>> > which is similar to Ido for buffer-switching.
>> >
>> > BTW, someone mentioned Ido's "flex" matching. That is also
>> > available with Icicles (I call it "scatter" matching).
>> > You can switch matching methods at any time by hitting
>> > `C-(' or `M-(' in the minibuffer:
>> >
>> > * `C-(' cycles between fuzzy and prefix completion (for TAB)
>> > * `M-(' cycles between regexp/substring, scatter (flex), and
>> >   Levenshtein completion (for S-TAB)
>> >
>> > HTH.
>>
>> The above features of ido i mentioned are basically the daily
>> stuff i use and really missed when i tried icicles for some minutes.
>
> IIUC, the things you mentioned are available in Icicles as well.
>
> I would say, however, that if you are happy with Ido (or with vanilla Emacs, for
> that matter), then why change? I meant it when I said that it's probably a
> mistake to look for a reproduction of Ido behavior in Icicles; you're bound to
> be disappointed at some point.
>
> We each have our own preferences and habits. The old saying that "if all you
> have is a hammer then everything looks like a nail" is apt here. If someone is
> quite used to a hammer (whether that's Ido or vanilla Emacs or Icicles), then,
> when trying out a different tool, there is often a tendency to find it lacking
> in hammerness. ;-) Each tool has its advantages - no sense using a wrench only
> to pound on things. Instead, find out how a wrench might be useful to you (or
> not).
>
> People are different. It's a good thing that there are multiple UIs available to
> choose from and experiment with. There is no single best answer.
>
> Just wanted to offer some general clarification, in case it helps someone.
>
>
>
>
>



-- 
For personal and corporate gain, myalgic encephalomyelitis denialists
are knowingly causing massive suffering and 25-years-early death by
grossly corrupting science.
http://www.meactionuk.org.uk/What_Is_ME_What_Is_CFS.htm




  parent reply	other threads:[~2009-02-01 22:43 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-31 11:06 What completion mechanisms are you using? senny
2009-01-31 11:42 ` Les Harris
2009-02-01  1:30   ` Samuel Wales
2009-02-01 10:06   ` Christian Engels
2009-02-01 12:52   ` Christian Engels
2009-02-01 16:09     ` Drew Adams
2009-02-01 18:43       ` Christian Engels
     [not found]         ` <002501c984af$d8818580$0200a8c0@us.oracle.com>
2009-02-01 22:43           ` Samuel Wales [this message]
2009-02-01 23:33             ` Drew Adams
2009-02-01 23:57               ` Samuel Wales
2009-02-02  0:37               ` Samuel Wales
2009-02-02  0:24           ` Drew Adams
     [not found]           ` <mailman.6468.1233534260.26697.help-gnu-emacs@gnu.org>
2009-02-02  0:41             ` Richard Riley

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=20524da70902011443i1425ed8scaabc701c32c4417@mail.gmail.com \
    --to=samologist@gmail.com \
    --cc=drew.adams@oracle.com \
    --cc=help-gnu-emacs@gnu.org \
    --cc=s9chenge@stud.uni-saarland.de \
    /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.
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).