[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