help-gnu-emacs
[Top][All Lists]
Advanced

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

RE: migrating from ido to icicles


From: Drew Adams
Subject: RE: migrating from ido to icicles
Date: Wed, 19 Dec 2012 14:41:13 -0800

> I'm trying to use icicles exclusively and not use ido anymore.

This page might help in that regard, in general:
http://www.emacswiki.org/emacs/Icicles_-_Ido_and_IswitchB

> There's one sticking point left, and that's how icicles deals 
> with filename completion.
> 
> The problem is with drilling down directory levels.  It seems 
> to be that once completion is active, both TAB and the cycle 
> keys do the same thing.  The only way to say "I accept the 
> currently highlighted directory candidate, drill down to 
> start completing the next one" is M-SPC.

Actually, `M-TAB' does what you want here only because it does "word"
completion, which also moves the cursor to the end of the completion.  It is
that cursor movement that switches from cycling back to completing.

In Icicles, cycling fills the minibuffer with a candidate, which you can edit
etc. normally.  In this it is quite different from Ido, IswitchB, and Icomplete,
which display candidates in the minibuffer but not as input to be edited
directly.

Icicles needs to know whether the input in the minibuffer is the result of
cycling or of editing or completing.  When you have been cycling, if you do
something other than hit a cycling key (or a scrolling key etc.) then it cancels
cycling - your action is taken as "editing" the cycled candidate.

Repeating TAB (or S-TAB) cycles among the current candidates.  And if one of
those (filename) candidates is a directory name then it is handled just like the
other, non-directory candidates: (a) cycling moves on from it to the next
candidate, and (b) RET (or C-RET) visits that directory using Dired.

IOW, a directory-name candidate is treated during cycling just like a file name.

But you can complete without cycling or after cycling a bit: If your input
matches only a unique directory name then TAB (or S-TAB) completes to that name.
Then a second TAB (or S-TAB) uses that directory not as a candidate but as the
base directory in which to complete.  IOW, it shows you all the files in that
directory as candidates.

IOW, the contents of the minibuffer are interpreted differently depending on
whether they are the result of completing or editing on the one hand, or cycling
on the other hand.  Cycling does not change the `default-directory' or the
current set of candidates.  Completion and editing can change both.

So all you really need to do is to change from cycling to "editing", to get
Icicles to interpret the current minibuffer content as a new starting point for
file-name completion, i.e., in this case as the new `default-directory'.

"Editing" really means doing pretty much anything other than cycling.  Just
moving the cursor, for instance.  What users typically do to drill down through
a directory that they have reached by cycling, is to hit `C-e' or `C-f' etc.,
and then hit TAB to complete the files in that directory.  E.g.:

C-x C-f con TAB TAB ... ; cycle until you get to CONTRIB/
C-e TAB                 ; complete in directory CONTRIB/

Or as I said, you can also not bother with cycling and just use completion.
E.g.:

C-x C-f cont TAB ; assuming only one match for that input

Or include progressive completion.  E.g.:

C-x C-f c TAB M-SPC ib S-TAB ; complete prefix `c', then match `ib'

> What I want is just for completion of filenames, for TAB to 
> only activate completion, and if it's already active, do what 
> M-SPC currently does. Leave cycling for keys bound 
> specifically for that purpose.

Long ago Icicles used TAB and S-TAB only for completion, not also for cycling as
now.  If there were a demand for this it could be optional, but today it is not.

If you want that behavior, replace
`icicle-next-(prefix|apropos)-complete-cycles-p' with `nil' wherever its value
is used in `icicles-mcmd.el'.  (You still do have other keys that perform only
cycling.)

HTH.




reply via email to

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