all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Jeff Weiss <jweiss@redhat.com>
To: Drew Adams <drew.adams@oracle.com>,
	jeffrey.m.weiss@gmail.com, help-gnu-emacs@gnu.org
Subject: RE: migrating from ido to icicles
Date: Thu, 20 Dec 2012 09:51:41 -0500	[thread overview]
Message-ID: <874njgrd36.fsf@blinky.jweiss.com> (raw)
In-Reply-To: <728806CAFD184E6582CE77D11D5802CB@us.oracle.com>

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	other threads:[~2012-12-20 14:51 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-19 19:11 migrating from ido to icicles jeffrey.m.weiss
2012-12-19 22:41 ` Drew Adams
2012-12-20 14:51   ` Jeff Weiss [this message]
2012-12-20 15:45     ` Drew Adams
2012-12-20 21:11       ` Jeff Weiss
     [not found] ` <mailman.15718.1355956885.855.help-gnu-emacs@gnu.org>
2012-12-20 12:31   ` Michael Heerdegen
2012-12-21  0:10     ` Drew Adams
  -- strict thread matches above, loose matches on Subject: below --
2012-12-20 22:30 Drew Adams
2012-12-21  3:53 ` Jeff Weiss
2012-12-21 18:31   ` Drew Adams
2012-12-21 14:41 ` Jeff Weiss
2012-12-21 18:32   ` Drew Adams
2012-12-21 19:06     ` Jeff Weiss
2012-12-21 19:12       ` Drew Adams

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874njgrd36.fsf@blinky.jweiss.com \
    --to=jweiss@redhat.com \
    --cc=drew.adams@oracle.com \
    --cc=help-gnu-emacs@gnu.org \
    --cc=jeffrey.m.weiss@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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.