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: Jeff Weiss
Subject: RE: migrating from ido to icicles
Date: Thu, 20 Dec 2012 09:51:41 -0500
User-agent: Notmuch/0.13.2 (http://notmuchmail.org) Emacs/24.1.1 (x86_64-redhat-linux-gnu)

Drew Adams <drew.adams@oracle.com> writes:

>> 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.

"M-TAB (translated from <M-tab>) runs the command complete-symbol, which
is an interactive compiled Lisp function in `bindings.el'."

"M-SPC runs the command icicle-prefix-word-complete, which is an
interactive compiled Lisp function in `icicles-mcmd.el'."

What happens for me is, if I hit M-TAB, point does not move, but the
mode line for the completions buffer switches from showing file
attributes back to showing the completion settings.  If I then hit TAB,
it completes using the current selection instead of cycling.
Unfortunately, the minibuffer is then filled with the first candidate in
the next directory level, which I don't want.

This is different than what either M-SPC or C-e does, they both appear
to only change the default-directory and the candidates, no candidate
shows in the minibuffer.  That's what I want. 

I like the behavior of M-SPC or C-e but I prefer to use M-TAB key to get
that behavior.  Should I just rebind it?

 
> 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.

Thanks very much for the detailed explanation.  I'll have to experiment
to see if I can get what I need without modifying the source.

-Jeff



reply via email to

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