shell command completion gone

shell command completion gone

[prad]

when i do M-!, type a few characters and then press tab it used to
complete. suddenly it doesn't anymore. the only thing i can think of
having done is that i reinstalled icicles from the site (not my arch
distribution), but i don't see what that would have to do with it,
because it doesn't use icicles afaik.

if i go into a shell, everything completes just fine.

what does completion depend upon for the shell command?

-- 
in friendship,
prad

RE: shell command completion gone

[Drew Adams]

> when i do M-!, type a few characters and then press tab it used to
> complete. suddenly it doesn't anymore. the only thing i can think of
> having done is that i reinstalled icicles from the site (not my arch
> distribution), but i don't see what that would have to do with it,
> because it doesn't use icicles afaik.
> 
> if i go into a shell, everything completes just fine.
> what does completion depend upon for the shell command?

Yes, it is because by default Icicles provides a different kind of completion
for shell commands.  Admittedly, this has confused more than one person.

You can customize option `icicle-redefine-standard-commands-flag' to `nil' to
restore the vanilla Emacs behavior here, if that's what you prefer.


For info about this completion:
http://www.emacswiki.org/emacs/Icicles_-_Shell-Command_Enhancements

There are 3 possible sources of completion candidates here:

1. Programs on your $PATH (if `icicle-guess-commands-in-path' is non-nil), as
proxy candidates.  (nil is the default value.)

2. Programs deemed appropriate for the target file types, as proxy candidates.
E.g., in Dired, `gunzip -qc * | tar xvf -' might be a candidate command for
target file `foo.tgz'.

3. Programs anywhere - file names.

To make #1 and #2 available, you must turn on proxy candidates (if off).  Use
`C-M-_' during completion to do that (once).  (You can customize option
`icicle-add-proxy-candidates-flag' to turn it on by default.)

Wrt #3: Icicles completion here is file-name completion, to let you complete
against command files anywhere, not just those on your $PATH.  It is this that
is particularly confusing at first (unexpected).

The idea is that not every program/command you might want to use is on your PATH
or preconfigured by a file-type association.  The former is especially true on
Windows, I think - PATH is not used as much on Windows, especially by users who
do not program on Windows (which means most Windows users).

For #2, there are in turn two sources of "appropriate" programs:

2a. Whatever `dired-guess-default' guesses for the target files.  This is
determined by variable `dired-guess-shell-alist-default' and user option
`dired-guess-shell-alist-user'.  This is available only if you load
`dired-x.el'.

2b. Whatever `mailcap-file-default-commands' returns for the target files (based
on MIME types of the target files).  This is only for Emacs 23 and later.

Note that #2 is true in Dired for `!' and outside Dired for `M-!' (provided you
load `dired-x.el').  These candidates are available whenever a shell command is
read in Icicles.

File-name completion is very different from command completion, so in order to
allow completion of arbitrary program files I opted for file-name completion and
then brought in proxy candidates for the known commands (those on $PATH and the
others mentioned above).

When you complete, the proxy candidates are sorted first, and they are
highlighted specially in *Completions* for easy recognition.

If `icicle-guess-commands-in-path' is nil (the default), then the only proxy
candidates are those from #2: programs that are known to be appropriate
candidates for the file type in question.  This takes effect in contexts such as
Dired where the files that are the targets of the command you will choose are
already known.  E.g., for a PDF file in Dired, `!' will include commands such as
`gv -safer', `xpdf', and `pdftotext ? -'.

Sorry for any confusion.  HTH.
  

Re: shell command completion gone

[prad]

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

> Sorry for any confusion.
drew thank you very much for that detailed explanation.
i have things working fine now using M-/
icicles is a wonderful addition!

-- 
in friendship,
prad

Re: shell command completion gone

[rusi]

On Jan 8, 9:02 am, prad <p...@towardsfreedom.com> wrote:
> "Drew Adams" <drew.ad...@oracle.com> writes:
> > Sorry for any confusion.
>
> drew thank you very much for that detailed explanation.
> i have things working fine now using M-/
> icicles is a wonderful addition!
>
> --
> in friendship,
> prad

Hi Prad.
Do you think you could spell out some (say 5-10) typical use-cases of
icicles?
Reason I ask: Ive tried a couple of times to use icicles but could not
get into it

Re: shell command completion gone

[prad]

rusi <rustompmody@gmail.com> writes:

> Hi Prad.
> Do you think you could spell out some (say 5-10) typical use-cases of
> icicles?
> Reason I ask: Ive tried a couple of times to use icicles but could not
> get into it
>
certainly rusi and i appreciate your asking this since i tend to just
use it very passively being effectively a newbie. exploring the package
further gets you to really appreciate the wonderful work it really is!

* ideas on icicles 
these are just some basic explorations of what you
can do with drew adam's enormously helpful icicles package.


** cycling completions
ref: http://www.emacswiki.org/emacs/Icicles_-_Cycling_Completions
use <home>,<end> keys to cycle through all possibilities in minibuffer
use <tab> to cycle as well and see possibilities in a separate buffer too

ex: C-x C-f and use those keys to cycle through available files
ex: C-h C-i m and cycles through topics in info
ex: C-x b and cycle through your buffer choices
ex: C-h v, type gnu and cycle through all variable which begin with
"gnu"



** apropos completion via regexp
ref: http://www.emacswiki.org/emacs/Icicles_-_Apropos_Completions
use <page up>,<page down> for matching regexp anywhere (instead of just
prefix as with gnu ex above)
use S-<tab> to see all items which have regexp in them in separate buffer

ex: M-x line and use those keys to cycle through all commands which has
"line"
ex: M-x tran.*line and use those keys to find "transpose-lines" right
away
ex: M-x line S-<tab> to see all commands which have "line" in them
ex: C-x b at and use those keys to cycle through all buffers with "at"
in them



** input history completion
if you want to see what you have actually done yourself instead of what
is available, just use M-n, M-p which let you traverse your own input
history

ex: visit some buffers then C-x b and M-n, M-p will show you where you
have been


** progressive completion ref:
http://www.emacswiki.org/emacs/Icicles_-_Progressive_Completion
analogous to sequential piping, this let's you narrow a search through
repeated internal matching using S-<spc> (or S-<tab> and repeated M-*)

ex: say you can't quite remember that the gnus-save-article-folder
command or may be it's gnus-save-folder-article or something with "save"
and "folder" anyway. so type C-h f gnus S-<spc> then S-<spc> save then
S-<spc> folder and this way you'll keep narrowing your search without
having to worry about the order of the components.


how's that for starters?

my uses are presently limited to command, help, buffer and file issues
but i'm wondering if i can make better use of it for ordinary text
completions too - sort of as a non-verbal speech recognition
mechanism. i think company.el may facilitate this idea, but i haven't
explored it yet.

-- 
in friendship,
prad

Re: shell command completion gone

[Le Wang]

[-- Attachment #1: Type: text/plain, Size: 2027 bytes --]

On Sun, Jan 9, 2011 at 6:11 AM, prad <prad@towardsfreedom.com> wrote:

> certainly rusi and i appreciate your asking this since i tend to just
> use it very passively being effectively a newbie. exploring the package
> further gets you to really appreciate the wonderful work it really is!
>

Considering everything in the package, it's difficult for anyone to not use
it "very passively".  I'm just getting reacquainted with it myself.  I think
Drew's approach in designing the package was to put everything under the sun
completion related in there and enable most of it by default.  The advantage
of this approach is people can discover features "by accident".  The
downside is the dramatic behavior changes can scare away people just testing
the waters.

Rest assured, though, *the behaviors you do not want can be disabled*.  And
if you notice something that could be a bug Drew is a super responsible and
responsive maintainer.

Here is the use-case I find useful above all else icicles offers:

I want help with the function that searches regexps backwards.  I know that
the keywords "backward" "regex" and "search" occurs in its name, but I don't
know in what order.  Normally I would have to apropos several possible
orders before finding the exact name.  With icicles, I can just use the `*
icicle-narrow-candidates*' to interactively filter the completion list, to
wit:


   1. <C-h>fregex<shift-tab>
   2. <M-*>back<shift-tab>
   3. <M-*>search<shift-tab>

After each step, the completion candidates are narrowed, and whenever the
list is short enough, I can pop into the completion list window and select
it myself.

Drew's analogy for this is shell piping into successive greps.  I often find
functions that I didn't know existed and are in fact better suited to my
purpose by using this narrowing tool.


The wiki is a great place to get more info on icicles.  Drew is very active
there.  Researching my little example above, I just found out that the
<S-tab><M-*> can be shortened to just <S-spc>.

hth.
-- 
Le

[-- Attachment #2: Type: text/html, Size: 2765 bytes --]

Icicles [was: shell command completion gone]

[Drew Adams]

Thanks for your kind words, Le and Prad.  I have a few comments, FWIW.

> > i tend to just use it very passively being effectively a
> > newbie. exploring the package further gets you to really
> > appreciate the wonderful work it really is!
>
> Considering everything in the package, it's difficult for
> anyone to not use it "very passively".  I'm just getting
> reacquainted with it myself.  I think Drew's approach in
> designing the package was to put everything under the sun
> completion related in there and enable most of it by default.
> The advantage of this approach is people can discover
> features "by accident".  The downside is the dramatic
> behavior changes can scare away people just testing the
> waters.

Actually, no, that's not the intention.  My approach is not to turn
everything on and hope that people "discover features by accident".
That the default Icicles behavior is different in some respects from
vanilla Emacs might sometimes give that impression, but that is not my
approach.


1. If you use only TAB to complete minibuffer input, and you do not do
anything that you wouldn't do anyway in the vanilla Emacs minibuffer,
then you should hardly notice being in Icicle mode.

That's modulo any bugs that might exist, of course.  And "hardly" is
not "never".

The point here is that Icicles features come primarily from binding
additional keys in the minibuffer.  In general, if you don't use those
keys in the minibuffer then you won't get special behavior.

And the keys in question are typically keys that you would not use for
editing text.  In Icicles it is especially important that you be able
to edit normally in the minibuffer.

Minibuffer text editing can be more important in Icicles than in
vanilla Emacs for several reasons, including because Icicles does not
avoid or prevent the use of completion candidates that contain spaces,
newlines, and so on.  You can enter such characters in the minibuffer
just as you would in any other buffer (hit `SPC', `C-j').  Likewise
`?'  characters.  No need to quote such chars using `C-q'.

Is this a case of non-vanilla behavior that might be surprising?  Yes.
Is it objectionable?  IMO, no.  (And you can easily turn it off.)

FWIW, vanilla Emacs itself finally came around (in version 22) to
letting `SPC' be self-inserting for file-name completion.  Perhaps
someday it will loosen up further in this regard. ;-)  In a
text-editing context, sacrificing a printable char such as `?' as a
help-command key is silly, IMO.  Anyway, if you're not used to such
keys self-inserting in the minibuffer then you might be surprised, but
probably not too disoriented.

Admittedly, a few of the keys that Icicles binds in the minibuffer for
special purposes are keys that you might normally use for editing, but
they are not so useful for editing in the minibuffer.  And they are
really the exception.

For example, `M-k' is normally `kill-sentence', but in the minibuffer
sentences are not very significant, so `M-k' in the Icicles minibuffer
empties the minibuffer completely.  Another example is `M-o': In the
Icicles minibuffer `M-o' invokes a recursive minibuffer to let you
complete against past inputs and insert them at the minibuffer cursor.
I figure that in the minibuffer you won't miss `M-o' as a facemenu
prefix key (`facemenu-keymap').  This is analogous to Dired mode
co-opting `M-o' for `dired-omit-mode'.  Again, such keys are the
exception; Icicles has respect for keys that edit.


2. It is not unusual that someone who might be attracted to Icicles
for some of its features comes not from vanilla Emacs but from some
other package that also provides enhanced completion or cycling - Ido
or Iswitchb, for instance.  That makes sense: they've already been
looking for something On Beyond Vanilla.

In that case they may already be used to a different minibuffer UI
from the vanilla one.  They can thus have particular expectations that
conflict with the Icicles UI.  Things like incremental completion and
cycling among candidates are different in Icicles.

In general, Icicles minibuffer behavior is closer to the vanilla Emacs
behavior: you type and edit, hit TAB to complete if you want, and then
hit RET to accept/commit your input.  When you cycle, the current
candidate takes the place of your minibuffer input, so you can edit it
normally.  Icicles is not Ido.


3. My approach to default behavior is to aim for a good overall
experience, where the various features fit together well.  At the same
time, I aim for what I expect to be the average Icicles user,
typically based on what I expect are pretty average preferences and
uses of vanilla Emacs.

For example, I do not set Icicles default values to the values that I
myself use.  I set them to what I expect will be most useful for most
people.

You would (or perhaps would not) be surprised at the number of people
who have different preferences and think that a default behavior
should be changed.  Users sometimes do not think, like maintainers do,
in terms of other users - they sometimes think that what is most
natural and most useful is what _they_ happen to prefer.  As users we
are probably all guilty of that.  So there is always someone who
thinks that some default behavior is a bad choice.

I aim to have the default settings provide a good combination overall
for using Icicles.  Things are designed to fit together and take good
advantage of what Icicles has to offer (synergy).  Think of this
approach to defaults as being "what is best for using Icicles" - for
most use cases.  That's the aim, anyway.

That's not the same as throwing everything at you so you are forced to
discover features by accident, as gotchas.  The latter might appear to
be the case, but it is not.  I think a lot about the defaults, and I
try to document things well, including how to turn things off and how
to customize.


5. I recommend that new Icicles users at least try the default
settings, in particular the default key bindings, for a little while
before deciding to customize them.

Because someone new to Icicles is not yet familiar with the features
and how they fit together, it can be tempting to want to customize
things immediately, to shoot for the keys you are used to, etc.  That
is like a VI user switching to Emacs and wanting to use a VI emulator
to support the habit.

You can do that - nothing wrong with it, but if you do you will not
necessarily learn what Icicles or Emacs really has to offer, in terms
of synergy: how one part can help another part do things better.

Especially since, starting out, you likely will not use many of the
Icicles features at first.  If all you do is complete and cycle then
you might not see why some of the defaults are as they are.  They are
as they are for use of Icicles as a whole.


5. Generally speaking, Icicles takes place in the minibuffer, and in
general it does not affect top-level commands.  But it is true that
there are some exceptions.  They are not there so that you fall into
pit-holes or trip up by accident.  They are called out in the doc.
When top-level features are turned on by default it is because I think
they offer the best Icicles experience.

A typical example is an Icicles multi-command that replaces a standard
command.  For instance, `icicle-dired' is bound by default (in Icicle
mode) to `C-x d'.  It is just a multi-command version of `dired'.  If
you do nothing special it acts like `dired'.  But if you use some
additional keys in the minibuffer then you get additional behavior.

I could have opted not to bind any top-level commands such as
`icicle-dired', and just let users bind them if they want to.  I chose
to bind some by default - not so that users would accidentally come
across land mines, but because (a) I think they are not so different
that they should be found bothersome, (b) they are well documented,
including how to turn them off, and (c) the original behavior is
restored when you turn off Icicle mode.


6. That last point is important: I try to corral all of the Icicles
weirdness within Icicle minor mode: turn it off and Icicles goes away.
That's not so easy to do, BTW.  Lots of hoops are jumped through to
try to do that cleanly.  I doubt that this is 100% perfect, but it is
pretty good.

Icicles adds Icicle-mode key bindings, and it changes some minibuffer
key bindings when you are in Icicle mode.  In general, it does not
change key bindings in other key maps (`global-map', major-mode maps,
or minor-mode maps), with the exceptions mentioned below (#7).


7. It is straightforward to tell Icicles not to change stuff.

* Set option `icicle-touche-pas-aux-menus' to `t' if you do not want
  Icicles to add stuff to existing menu-bar menus.

* Customize option `icicle-top-level-key-bindings' to remove or change
  any top-level bindings you want.  If you set this option to `nil'
  then Icicles does not add or change any top-level keys.

  I created this option to make it easy for anyone, including
  non-Lispers, to customize keys or remap commands, even
  conditionally.  Here's a picture and an explanation:
  http://www.emacswiki.org/emacs/Icicles_-_Key_Bindings#IcicleModeBindings

* Set option `icicle-redefine-standard-commands-flag' to `nil' if you
  do not want Icicles to bind any keys in particular modes.  E.g., by
  default, in `Info' mode Icicles rebinds `i', `g', and `m' to
  multi-command versions of the vanilla commands.

> Rest assured, though, the behaviors you do not want can be disabled.
> And if you notice something that could be a bug Drew is a super
> responsible and responsive maintainer.
>
> Here is the use-case I find useful above all else icicles offers:

...[description of progressive completion to find a function name]...

> The wiki is a great place to get more info on icicles.  Drew is
> very active there.  Researching my little example above, I just
> found out that the <S-tab><M-*> can be shortened to just <S-spc>.

I recommend the following page for info about things like that.  It
gives a good idea how Icicles can help you _ask Emacs about itself_:
http://www.emacswiki.org/emacs/EmacsNewbieWithIcicles

Yes, there is a lot in Icicles - more than I use myself very often.
(I don't develop software for a living anymore.  I use Emacs just to
fart around. ;-))

Besides being unaware of some Icicles features, it's of course easy to
forget some of them - minibuffer key bindings, for instance.  Just
remember one: `C-?' in the minibuffer is your friend.  It reminds you
about key bindings and gives you an instant link to all of the Icicles
doc.

HTH.

Re: Icicles [was: shell command completion gone]

[rusi]

On Jan 12, 4:21 am, "Drew Adams" <drew.ad...@oracle.com> wrote:
> For example, I do not set Icicles default values to the values that I
> myself use.  I set them to what I expect will be most useful for most
> people.
>
> You would (or perhaps would not) be surprised at the number of people
> who have different preferences and think that a default behavior
> should be changed.  Users sometimes do not think, like maintainers do,
> in terms of other users - they sometimes think that what is most
> natural and most useful is what _they_ happen to prefer.  As users we
> are probably all guilty of that.  So there is always someone who
> thinks that some default behavior is a bad choice.
>
> I aim to have the default settings provide a good combination overall
> for using Icicles.  Things are designed to fit together and take good
> advantage of what Icicles has to offer (synergy).  Think of this
> approach to defaults as being "what is best for using Icicles" - for
> most use cases.  That's the aim, anyway.
>
> That's not the same as throwing everything at you so you are forced to
> discover features by accident, as gotchas.  The latter might appear to
> be the case, but it is not.  I think a lot about the defaults, and I
> try to document things well, including how to turn things off and how
> to customize.

I of course appreciate that as the developer's/envisioner's view.
But just see what its like from that of a wannabe user (like but not
restricted to yours truly :-)
He has a stark 0 1 infinity choice:
0. No icicles
1. Use icicles with defaults as given
infinity. tweak and understand every available option

How could this be improved?
I'm putting together 2 ideas
1. Ive heard Alan Mackenzie use the word 'emacsicality' for a
collection of (semi)coherent customizations
2. viper mode has a zillion customizations collected into 5 'levels'

So the viper solution for icicles would be to have say 3-4 levels of
icicles ranging from plain vanilla emacs to expert.
But there is a less technological solution which will certainly be
easier on Drew but likely also on the typical emacs user:

Put up (on the wiki maybe) a bunch of customization-bundles
corresponding to common learning paths.
So the vanilla-user learning path would be as follows (One could
replace vanilla by ido and iswitch if desired; you get a few more
bundles)

bundle-0. All keys behave as in vanilla emacs; icicles functionality
available in a standard place such as a menu
bundle-1. A few key (sorry for the pun) concepts are understood and
their corresponding keys are bound; but ONLY those keys
bundle-2. More concepts and more keys
Stop at 3 or 4! [And thats not factorial!]

> Thanks for your kind words, Le and Prad.

I have taught programming for nearly 25 years and the most valuable
learning Ive got (which Ive unfortunately mostly wasted) is beginner
mistakes.  If I had a chance to go back I would collect the best
'mistakes'.

That is to say you need people like Le and Prad (and hopefully myself)
as control-points on the learning-bezier-curve.

Re: Icicles

[prad]

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

> Because someone new to Icicles is not yet familiar with the features
> and how they fit together, it can be tempting to want to customize
> things immediately, to shoot for the keys you are used to, etc.  That
> is like a VI user switching to Emacs and wanting to use a VI emulator
> to support the habit.
>
> You can do that - nothing wrong with it, but if you do you will not
> necessarily learn what Icicles or Emacs really has to offer, in terms
> of synergy: how one part can help another part do things better.
>
thank you drew for the detailed explanations and ideas. i feel doubly
fortunate that i get to use something as fine as icicles and have the
author as coach. it can't get any better!

for me, i think you have made a significant point through your
explanations. i likely try to fiddle with too much too soon and should
make more of an effort to understand the capabilities and intent of the
software's defaults so as to get my bearings right first.

i acknowledge this can be difficult to do when there is such a wealth of
items available through something like emacs. while trying to learn
gnus, i wanted to learn how to use icicles better and that led me
somehow to org. so i've joined all the relevant groups and spend more
time reading the posts (of people wanting to implement things and others
coming up with neat solutions that i don't always understand) than
working on learning the software. self-discipline is definitely what is
required!

imho, open source is the next best thing to sliced bread (thx to people
like you who generously create things we all can use) ... and since i
don't eat bread, it's pretty well number one on my list!

-- 
in friendship,
prad

RE: Icicles [was: shell command completion gone]

[Drew Adams]

> bundle-0. All keys behave as in vanilla emacs; icicles functionality
> available in a standard place such as a menu

That's command `icy-mode': turns Icicles on (and off).

> bundle-1. A few key (sorry for the pun) concepts are understood and
> their corresponding keys are bound; but ONLY those keys

(setq icicle-touch-pas-aux-menus              t
      icicle-top-level-key-bindings           nil
      icicle-redefine-standard-commands-flag  nil)

Just use completion normally: TAB, RET (~ vanilla Emacs).

Later, try candidate cycling if you want.
Try `C-M-mouse-2' for help on a candidate, if you want.
Try substring completion (`S-TAB') if you want.

IOW, start with vanilla behavior; explore Icicles by experimenting with features
as slowly as you like.  There's nothing dangerous here.

There should be nothing confusing if you don't use keys you wouldn't normally
use in the minibuffer anyway.

> bundle-2. More concepts and more keys
> Stop at 3 or 4! [And thats not factorial!]

Au choix.  You don't need a bundle to activate a few keys.

(setq icicle-touch-pas-aux-menus  t)

Or just add back a few of the default keys to `icicle-top-level-key-bindings'.
Experiment with the ones you added before moving on.

> That is to say you need people like Le and Prad (and hopefully myself)
> as control-points

Yes, any maintainer/developer would be lost without user feedback.  Many users
have helped Icicles along the way, and I and other users appreciate it.

> on the learning-bezier-curve.

IMO, Icicles can help with both the Emacs learning curve and the Icicles
learning curve.  Believe it or not...

RE: Icicles

[Drew Adams]

> while trying to learn gnus, i wanted to learn how to use
> icicles better and that led me somehow to org.

In such a situation, it might be a good idea to use Icicles only as an aid to
learning gnus and org, for now.  So you might want to turn off the following for
the time being, while you learn gnus and org:

(setq icicle-top-level-key-bindings           nil
      icicle-redefine-standard-commands-flag  nil)

More variables means more confusion.  Tiny bites swallowed finishes the slice of
bread first (learned that in an elementary-school contest - lost).

> imho, open source is the next best thing to sliced bread

Free and open software is much better than sliced bread - or at least better
than some sliced bread. ;-)

Re: Icicles [was: shell command completion gone]

[Rustom Mody]

Hi Drew.

Not used icicles for a while...
This thread prompted me to try again

Reinstalling: The get icicles shell script missed ring+.el.  Anyway
thats a minor point

On Wed, Jan 12, 2011 at 9:15 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> bundle-0. All keys behave as in vanilla emacs; icicles functionality
>> available in a standard place such as a menu
>
> That's command `icy-mode': turns Icicles on (and off).

Well I find that uparrow and downarrow in vanilla (aided with
savehist) gets me history
But icicles gets me the 2C-associate-buffer
(Seems to have recently changed from forward to reverse or some such
so now gives
zone-mode)
In any case vanilla gives history icicles gives all possible completions


Another thing about icicles that got in my way earlier (dunno if
changed recently) is that icicles stay around and show up unexpectedly
and uselessly when for example I kill another buffer
>
>> bundle-1. A few key (sorry for the pun) concepts are understood and
>> their corresponding keys are bound; but ONLY those keys
>
> (setq icicle-touch-pas-aux-menus              t
>      icicle-top-level-key-bindings           nil
>      icicle-redefine-standard-commands-flag  nil)
>
> Just use completion normally: TAB, RET (~ vanilla Emacs).
>
> Later, try candidate cycling if you want.
> Try `C-M-mouse-2' for help on a candidate, if you want.
> Try substring completion (`S-TAB') if you want.
>
> IOW, start with vanilla behavior; explore Icicles by experimenting with features
> as slowly as you like.  There's nothing dangerous here.
>
> There should be nothing confusing if you don't use keys you wouldn't normally
> use in the minibuffer anyway.
>
>> bundle-2. More concepts and more keys
>> Stop at 3 or 4! [And thats not factorial!]
>
> Au choix.  You don't need a bundle to activate a few keys.
>
> (setq icicle-touch-pas-aux-menus  t)
>
> Or just add back a few of the default keys to `icicle-top-level-key-bindings'.
> Experiment with the ones you added before moving on.
>
>> That is to say you need people like Le and Prad (and hopefully myself)
>> as control-points
>
> Yes, any maintainer/developer would be lost without user feedback.  Many users
> have helped Icicles along the way, and I and other users appreciate it.
>
>> on the learning-bezier-curve.
>
> IMO, Icicles can help with both the Emacs learning curve and the Icicles
> learning curve.  Believe it or not...
>
>

Re: Icicles [was: shell command completion gone]

[rusi]

On Jan 14, 12:30 pm, Rustom Mody <rustompm...@gmail.com> wrote:
> Another thing about icicles that got in my way earlier (dunno if
> changed recently) is that icicles stay around and show up unexpectedly
> and uselessly when for example I kill another buffer

Typo: I meant icicles completion *buffers*

RE: Icicles [was: shell command completion gone]

[Drew Adams]

Hi Rustom,

If you think you've found an Icicles bug, please use `M-x
icicle-send-bug-report'.

> Reinstalling: The get icicles shell script missed ring+.el.
> Anyway thats a minor point

I did not write `get-icicles.sh', but I've just added `ring+.el' to its list of
optional libraries for Icicles - thanks.  It is not a required library, but it
is used by one of the other libraries which is in the `get-icicles' optional
list.

> Well I find that uparrow and downarrow in vanilla (aided with
> savehist) gets me history But icicles gets me the 2C-associate-buffer

By default, `up' and `down' (arrows) in Icicles do not cycle history entries.
They cycle completion candidates per the current completion mode (e.g. prefix or
apropos).  By default the current mode is prefix completion.

To cycle history entries use `M-n' and `M-p' (or change the keys to suit
yourself).  This is all in the doc.

> (Seems to have recently changed from forward to reverse or some such
> so now gives zone-mode)

Dunno what you mean.  There has been no change in either cycle order or
candidate sort order.

Apparently you were completing command names (`M-x'), and you cycled using `up'.
In that case, assuming the default sort order (alphabetical), the first
candidate presented is something like `zone-mode' (up from the last).  If you
use `down' instead, then the first candidate alphabetically is cycled first,
e.g., `2c-associate-buffer'.

You can change the candidate sort order using `C-,'.  You can reverse the
current sort order using `C-1 C-,' (any numeric prefix arg with `C-,').  If you
accidentally hit, say, `C-1 C-,' and if the current sort order is alphabetical,
then you get a reverse alphabetical sort: `down' then sorts up from z to a, and
`up' sorts down from a to z, the opposite of usual.

> Another thing about icicles that got in my way earlier (dunno if
> changed recently) is that icicles stay around and show up unexpectedly
> and uselessly when for example I kill another buffer

Sorry, no idea what you mean, even after your later correction, which I don't
understand either:

> Typo: I meant icicles completion *buffers*

If you kill a buffer it stays killed, in Icicles as in Emacs.  And there is only
one completion buffer in Icicles (and typically in Emacs): `*Completions*'.

If you kill a buffer without also deleting its window, then another buffer takes
its place in the window.  That's not special to Icicles.  (Personally, I bind
`C-x k' to a command that deletes the window in addition to killing the buffer.)

Again, if you think you come across a bug, please file a report (starting from
emacs -Q etc.).  Thx.

Re: Icicles [was: shell command completion gone]

[rusi]

On Jan 14, 2:04 pm, "Drew Adams" <drew.ad...@oracle.com> wrote:
> Hi Rustom,
>
> If you think you've found an Icicles bug, please use `M-x
> icicle-send-bug-report'.
>
> > Reinstalling: The get icicles shell script missed ring+.el.
> > Anyway thats a minor point
>
> I did not write `get-icicles.sh', but I've just added `ring+.el' to its list of
> optional libraries for Icicles - thanks.  It is not a required library, but it
> is used by one of the other libraries which is in the `get-icicles' optional
> list.
>
> > Well I find that uparrow and downarrow in vanilla (aided with
> > savehist) gets me history But icicles gets me the 2C-associate-buffer
>
> By default, `up' and `down' (arrows) in Icicles do not cycle history entries.
> They cycle completion candidates per the current completion mode (e.g. prefix or
> apropos).  By default the current mode is prefix completion.
Yes I know
>
> To cycle history entries use `M-n' and `M-p' (or change the keys to suit
> yourself).  This is all in the doc.
Yes. I was just pointing out that that is not vanilla emacs -- your
earlier point was that simply using icy-mode without customizations
gives you vanilla behavior.
>
> > (Seems to have recently changed from forward to reverse or some such
> > so now gives zone-mode)
>
> Dunno what you mean.  There has been no change in either cycle order or
> candidate sort order.
>
> Apparently you were completing command names (`M-x'), and you cycled using `up'.
> In that case, assuming the default sort order (alphabetical), the first
> candidate presented is something like `zone-mode' (up from the last).  If you
> use `down' instead, then the first candidate alphabetically is cycled first,
> e.g., `2c-associate-buffer'.
>
> You can change the candidate sort order using `C-,'.  You can reverse the
> current sort order using `C-1 C-,' (any numeric prefix arg with `C-,').  If you
> accidentally hit, say, `C-1 C-,' and if the current sort order is alphabetical,
> then you get a reverse alphabetical sort: `down' then sorts up from z to a, and
> `up' sorts down from a to z, the opposite of usual.
>
> > Another thing about icicles that got in my way earlier (dunno if
> > changed recently) is that icicles stay around and show up unexpectedly
> > and uselessly when for example I kill another buffer
>
> Sorry, no idea what you mean, even after your later correction, which I don't
> understand either:
>
> > Typo: I meant icicles completion *buffers*
>
> If you kill a buffer it stays killed, in Icicles as in Emacs.  And there is only
> one completion buffer in Icicles (and typically in Emacs): `*Completions*'.

I see that the behavior is different than the last I saw.  The icicles
completion buffer is still around and still useless (bringing it up
and clicking something in it gives me minibuffer is not active for
completion) but it seems to be 'buried' deeper than earlier so it does
not get so much in the way.

[Interestingly if I make the minibuffer active say with a M-x and then
click one of the (earlier) completion entries I get args out of range]

>
> If you kill a buffer without also deleting its window, then another buffer takes
> its place in the window.  That's not special to Icicles.  (Personally, I bind
> `C-x k' to a command that deletes the window in addition to killing the buffer.)
>
> Again, if you think you come across a bug, please file a report (starting from
> emacs -Q etc.).  Thx.

RE: Icicles [was: shell command completion gone]

[Drew Adams]

> > By default, `up' and `down' (arrows) in Icicles do not 
> > cycle history entries.  They cycle completion candidates...
>
> Yes I know
>
> > To cycle history entries use `M-n' and `M-p' (or change the 
> > keys to suit yourself).  This is all in the doc.
>
> Yes. I was just pointing out that that is not vanilla emacs -- your
> earlier point was that simply using icy-mode without customizations
> gives you vanilla behavior.

I did not say that.  I said that if you use the usual keys in the minibuffer
then "you should hardly notice being in Icicle mode."  To which I took the
trouble to point out that "`hardly' is not `never'", which is a caveat
recognizing that there are some differences.

`M-n' and `M-p' are standard keys for cycling history in vanilla Emacs.  They
are the original keys for this, the most commonly documented keys for it, and
they work on nearly every keyboard.  In Icicles too they cycle the input
history.

It is true that vanilla Emacs also assigns `down' and `up' for cycling history,
and Icicles assigns these keys, by default, to cycling candidates.

This is all documented.  I wrote a fairly lengthy mail, but if you want a more
exact description then consult the doc.  It doesn't help anyone to repeat such
details here, IMO.

But you say you already knew this about history cycling.  So perhaps your point
was that I am misrepresenting things.

I think my representation was a fair and accurate general statement about a
typical user: if you stick to the usual keys in the minibuffer then you will
hardly notice being in Icicle mode.  You are free to disagree.

> I see that the behavior is different than the last I saw.  The icicles
> completion buffer is still around

The buffer has always been kept around.  The *Completions* window is deleted,
that's all; the buffer is not killed.  (Vanilla Emacs does not even remove the
window.)

My uninformed guess is that you have upgraded to a more recent Emacs version and
its choice of the buffer that is displayed when you kill a buffer has changed,
so that now you are more often seeing *Completions* displayed in the place of
some buffer that you have killed.

It is not Icicles that displays *Completions* then - Icicles is not "bringing it
up".  *Completions* is just one existing buffer among others, and for some
reason Emacs now decides that it is the one it wants to display for you in the
window of a buffer that you killed.

It's possible that *Completions* should be buried when its window is deleted, to
reduce the possibility that it will be substituted for a killed buffer.  Please
send a step-by-step bug report starting with emacs -Q, including your Emacs
version.

(I use a standalone *Completions* frame myself, so I don't see this problem.
And it has not been otherwise reported.)

> and still useless (bringing it up and clicking something
> in it gives me minibuffer is not active for completion) 

Of course.  There is no reason to click in it.  Icicles is not "bringing it up".
It is just being shown in place of a buffer that you killed (IIUC).  What you
want is for some other buffer to do that, not *Completions*.  Send an exact
recipe and I'll take a look - sounds like a call to `bury-buffer' might be
needed.

> but it seems to be 'buried' deeper than earlier so it does
> not get so much in the way.

Now I'm confused.  I thought you were describing a regression in behavior but
now it sounds like the behavior has actually improved.  Anyway, send me a recipe
to reproduce what annoys you and I'll take a look.

> [Interestingly if I make the minibuffer active say with a M-x and then
> click one of the (earlier) completion entries I get args out of range]

The old content of the *Completions* buffer is of course useless (except for
reference, to see what the candidates were for your last use), as you pointed
out.  You should not expect behavior different from what you describe in this
regard.  On the other hand, if you hit TAB after M-x then *Completions* should
be correctly updated to show the current candidates.

HTH.

Re: Icicles [was: shell command completion gone]

[Darth Emacs]

[-- Attachment #1: Type: text/plain, Size: 4809 bytes --]

Hi Drew,

By any chance could I talk you into posting your Icicles bindings. I would
enjoy getting a feel of how you think Icicles works best.

Best regards,
Darth Emacs

On Fri, Jan 14, 2011 at 9:48 AM, Drew Adams <drew.adams@oracle.com> wrote:

> > > By default, `up' and `down' (arrows) in Icicles do not
> > > cycle history entries.  They cycle completion candidates...
> >
> > Yes I know
> >
> > > To cycle history entries use `M-n' and `M-p' (or change the
> > > keys to suit yourself).  This is all in the doc.
> >
> > Yes. I was just pointing out that that is not vanilla emacs -- your
> > earlier point was that simply using icy-mode without customizations
> > gives you vanilla behavior.
>
> I did not say that.  I said that if you use the usual keys in the
> minibuffer
> then "you should hardly notice being in Icicle mode."  To which I took the
> trouble to point out that "`hardly' is not `never'", which is a caveat
> recognizing that there are some differences.
>
> `M-n' and `M-p' are standard keys for cycling history in vanilla Emacs.
>  They
> are the original keys for this, the most commonly documented keys for it,
> and
> they work on nearly every keyboard.  In Icicles too they cycle the input
> history.
>
> It is true that vanilla Emacs also assigns `down' and `up' for cycling
> history,
> and Icicles assigns these keys, by default, to cycling candidates.
>
> This is all documented.  I wrote a fairly lengthy mail, but if you want a
> more
> exact description then consult the doc.  It doesn't help anyone to repeat
> such
> details here, IMO.
>
> But you say you already knew this about history cycling.  So perhaps your
> point
> was that I am misrepresenting things.
>
> I think my representation was a fair and accurate general statement about a
> typical user: if you stick to the usual keys in the minibuffer then you
> will
> hardly notice being in Icicle mode.  You are free to disagree.
>
> > I see that the behavior is different than the last I saw.  The icicles
> > completion buffer is still around
>
> The buffer has always been kept around.  The *Completions* window is
> deleted,
> that's all; the buffer is not killed.  (Vanilla Emacs does not even remove
> the
> window.)
>
> My uninformed guess is that you have upgraded to a more recent Emacs
> version and
> its choice of the buffer that is displayed when you kill a buffer has
> changed,
> so that now you are more often seeing *Completions* displayed in the place
> of
> some buffer that you have killed.
>
> It is not Icicles that displays *Completions* then - Icicles is not
> "bringing it
> up".  *Completions* is just one existing buffer among others, and for some
> reason Emacs now decides that it is the one it wants to display for you in
> the
> window of a buffer that you killed.
>
> It's possible that *Completions* should be buried when its window is
> deleted, to
> reduce the possibility that it will be substituted for a killed buffer.
>  Please
> send a step-by-step bug report starting with emacs -Q, including your Emacs
> version.
>
> (I use a standalone *Completions* frame myself, so I don't see this
> problem.
> And it has not been otherwise reported.)
>
> > and still useless (bringing it up and clicking something
> > in it gives me minibuffer is not active for completion)
>
> Of course.  There is no reason to click in it.  Icicles is not "bringing it
> up".
> It is just being shown in place of a buffer that you killed (IIUC).  What
> you
> want is for some other buffer to do that, not *Completions*.  Send an exact
> recipe and I'll take a look - sounds like a call to `bury-buffer' might be
> needed.
>
> > but it seems to be 'buried' deeper than earlier so it does
> > not get so much in the way.
>
> Now I'm confused.  I thought you were describing a regression in behavior
> but
> now it sounds like the behavior has actually improved.  Anyway, send me a
> recipe
> to reproduce what annoys you and I'll take a look.
>
> > [Interestingly if I make the minibuffer active say with a M-x and then
> > click one of the (earlier) completion entries I get args out of range]
>
> The old content of the *Completions* buffer is of course useless (except
> for
> reference, to see what the candidates were for your last use), as you
> pointed
> out.  You should not expect behavior different from what you describe in
> this
> regard.  On the other hand, if you hit TAB after M-x then *Completions*
> should
> be correctly updated to show the current candidates.
>
> HTH.
>
>
>


-- 
* Darth Emacs *

“Duct tape is like the force. It has a light side, a dark side, and it holds
the universe together. <http://thinkexist.com/quotes/oprah_winfrey/>”

[-- Attachment #2: Type: text/html, Size: 5619 bytes --]

RE: Icicles [was: shell command completion gone]

[Drew Adams]

> By any chance could I talk you into posting your Icicles bindings.
> I would enjoy getting a feel of how you think Icicles works best.

1. There is no best.  For Icicles anymore than for Emacs.

Different people use Emacs/Icicles differently, and the same person uses them
differently at different times, in different contexts.

This is one reason that Icicles (a) has so many options and (b) has minibuffer
bindings to toggle or cycle many of those options - so that you can change the
behavior on the fly, depending on the context.  No one size fits all, especially
since Icicles applies to all kinds of minibuffer completion. 

2. My Emacs setup is particular, and that affects my preferences throughout
Emacs.  Among other things, I use a standalone minibuffer, and I generally use
frames where most people use windows.  My use of Emacs is also not average; in
particular, I do not use it to develop software (other than Emacs Lisp).

So an Emacs or Icicles setting that I find useful or comfortable might not be so
for someone else.


The main point is #1, however.  There is no best way to configure or use
Icicles.

FWIW, these are the Icicles options that I have customized for my own use (not
including `icicle-buffer-configs' and `icicle-saved-completion-sets', whose
values are just personal collections.

(custom-set-variables...
 '(icicle-bookmark-refresh-cache-flag nil)
 '(icicle-default-value (quote insert-end))
 '(icicle-highlight-input-completion-failure (quote implicit))
 '(icicle-regexp-search-ring-max 1000)
 '(icicle-search-ring-max 1000)
...)

This does not mean that these are settings are what I recommend for most people
or that these lead to the "best" way of working with Icicles/Emacs.  Far from
it.  But I post them since you asked.

Re: Icicles [was: shell command completion gone]

[rusi]

On Jan 14, 2:04 pm, "Drew Adams" <drew.ad...@oracle.com> wrote:
> Hi Rustom,
>
> If you think you've found an Icicles bug, please use `M-x
> icicle-send-bug-report'.

>
> > Another thing about icicles that got in my way earlier (dunno if
> > changed recently) is that icicles stay around and show up unexpectedly
> > and uselessly when for example I kill another buffer
>
> Sorry, no idea what you mean

Heres the behavior that does not make sense (to me)

emacs  ;; Start emacs. It starts in *scratch* buffer
info   ;; Start info with C-h i
m elisp ;; elisp node
m buffers TAB  ;; I get an icicles completion window with "buffers"
and "buffers and windows"
Select one of them
q  ;; exit info

Instead of putting me in the *scratch* buffer where I started its in
the "buffers" and "buffers and windows" completion window

RE: Icicles [was: shell command completion gone]

[Drew Adams]

> Instead of putting me in the *scratch* buffer where I started its in
> the ... completion window

Should be OK now. Thx.

Re: Icicles [was: shell command completion gone]

[Darth Emacs]

[-- Attachment #1: Type: text/plain, Size: 2326 bytes --]

many many thanks... new perspectives are fuel for creativity. I am also
using frames as opposed to windows. Welcome to the twenty-first century.
Hurrah!

On Sun, Jan 16, 2011 at 12:56 PM, Drew Adams <drew.adams@oracle.com> wrote:

> > By any chance could I talk you into posting your Icicles bindings.
> > I would enjoy getting a feel of how you think Icicles works best.
>
> 1. There is no best.  For Icicles anymore than for Emacs.
>
> Different people use Emacs/Icicles differently, and the same person uses
> them
> differently at different times, in different contexts.
>
> This is one reason that Icicles (a) has so many options and (b) has
> minibuffer
> bindings to toggle or cycle many of those options - so that you can change
> the
> behavior on the fly, depending on the context.  No one size fits all,
> especially
> since Icicles applies to all kinds of minibuffer completion.
>
> 2. My Emacs setup is particular, and that affects my preferences throughout
> Emacs.  Among other things, I use a standalone minibuffer, and I generally
> use
> frames where most people use windows.  My use of Emacs is also not average;
> in
> particular, I do not use it to develop software (other than Emacs Lisp).
>
> So an Emacs or Icicles setting that I find useful or comfortable might not
> be so
> for someone else.
>
>
> The main point is #1, however.  There is no best way to configure or use
> Icicles.
>
> FWIW, these are the Icicles options that I have customized for my own use
> (not
> including `icicle-buffer-configs' and `icicle-saved-completion-sets', whose
> values are just personal collections.
>
> (custom-set-variables...
>  '(icicle-bookmark-refresh-cache-flag nil)
>  '(icicle-default-value (quote insert-end))
>  '(icicle-highlight-input-completion-failure (quote implicit))
>  '(icicle-regexp-search-ring-max 1000)
>  '(icicle-search-ring-max 1000)
> ...)
>
> This does not mean that these are settings are what I recommend for most
> people
> or that these lead to the "best" way of working with Icicles/Emacs.  Far
> from
> it.  But I post them since you asked.
>
>


-- 
* Darth Emacs *

“Duct tape is like the force. It has a light side, a dark side, and it holds
the universe together. <http://thinkexist.com/quotes/oprah_winfrey/>”

[-- Attachment #2: Type: text/html, Size: 2824 bytes --]

Re: Icicles [was: shell command completion gone]

[rusi]

On Jan 14, 12:30 pm, Rustom Mody <rustompm...@gmail.com> wrote:
> Hi Drew.
> Well I find that uparrow and downarrow in vanilla (aided with
> savehist) gets me history
> But icicles gets me the 2C-associate-buffer
> (Seems to have recently changed from forward to reverse or some such
> so now gives
> zone-mode)
> In any case vanilla gives history icicles gives all possible completions

Trying to answer my own question:
Does
(setq icicle-default-cycling-mode 'history)
do what I want?

[Well it seems to as far as I can tell.  Just dunno about odd/corner
cases]

Re: Icicles [was: shell command completion gone]

[Le Wang]

[-- Attachment #1: Type: text/plain, Size: 819 bytes --]

The doc string on this variable explains it pretty well, no?

Setting icicle-default-cycling-mode to t was my first icicles customization.

On Fri, Jan 21, 2011 at 12:12 PM, rusi <rustompmody@gmail.com> wrote:

> On Jan 14, 12:30 pm, Rustom Mody <rustompm...@gmail.com> wrote:
> > Hi Drew.
> > Well I find that uparrow and downarrow in vanilla (aided with
> > savehist) gets me history
> > But icicles gets me the 2C-associate-buffer
> > (Seems to have recently changed from forward to reverse or some such
> > so now gives
> > zone-mode)
> > In any case vanilla gives history icicles gives all possible completions
>
> Trying to answer my own question:
> Does
> (setq icicle-default-cycling-mode 'history)
> do what I want?
>
> [Well it seems to as far as I can tell.  Just dunno about odd/corner
> cases]
>



-- 
Le

[-- Attachment #2: Type: text/html, Size: 1321 bytes --]

Re: Icicles [was: shell command completion gone]

[rusi]

On Jan 21, 10:18 am, Le Wang <l26w...@gmail.com> wrote:
> The doc string on this variable explains it pretty well, no?
>
> Setting icicle-default-cycling-mode to t was my first icicles customization.
>
>
>
> On Fri, Jan 21, 2011 at 12:12 PM, rusi <rustompm...@gmail.com> wrote:
> > On Jan 14, 12:30 pm, Rustom Mody <rustompm...@gmail.com> wrote:
> > > Hi Drew.
> > > Well I find that uparrow and downarrow in vanilla (aided with
> > > savehist) gets me history
> > > But icicles gets me the 2C-associate-buffer
> > > (Seems to have recently changed from forward to reverse or some such
> > > so now gives
> > > zone-mode)
> > > In any case vanilla gives history icicles gives all possible completions
>
> > Trying to answer my own question:
> > Does
> > (setq icicle-default-cycling-mode 'history)
> > do what I want?
>
> > [Well it seems to as far as I can tell.  Just dunno about odd/corner
> > cases]
>
> --
> Le

Well I dont know icicles well enough (or I am too dense) to see the
corner cases

RE: Icicles [was: shell command completion gone]

[Drew Adams]

> vanilla gives history icicles gives all possible completions
> Trying to answer my own question:

You didn't ask a question. ;-)

> Does (setq icicle-default-cycling-mode 'history)
> do what I want?

Dunno.  What do you want?

> [Well it seems to as far as I can tell.  Just dunno
> about odd/corner cases]

If you want up/down to _always_ cycle the history, then customize these options
accordingly: `icicle-modal-cycle-up-keys', `icicle-modal-cycle-down-keys'.
Replace `up' and `down' in the key lists with keys of your choice.

(If you do that, you might also want to change the similar options for keys that
cycle per-mode actions, alternate actions, and help, `C-down', `C-S-down',
`C-M-down', etc. for consistency.)


Option `icicle-default-cycling-mode' determines only the _default_ cycling mode:
the mode in effect if you do not specify the mode (i.e., before you specify it),
by hitting `TAB' (for prefix completion) or `S-TAB' (for apropos completion).
This option has no effect once you have specified the current cycling mode.

If you leave the default bindings for `icicle-modal-cycle-(up|down)-keys' as
`up' and `down', those two keys reflect the current completion mode.  They do
not cycle history once you have specified the current completion mode explicitly
(`TAB' or `S-TAB').

E.g., if you type `foo TAB', then `up' and `down' perform prefix-mode cycling,
not history cycling, regardless of the value of `icicle-default-cycling-mode'.
It is only before you hit either `TAB' or `S-TAB' that a default setting of
`icicle-default-cycling-mode' other than `prefix', `apropos', and `nil' cycles
the history.

,----
| icicle-default-cycling-mode is a variable defined in `icicles-opt.el'.
| Its value is prefix
| 
| Documentation:
| *Default completion mode for per-mode cycling.
| When you hit a completion key (`TAB' or `S-TAB'), it sets the current
| completion mode (prefix or apropos, respectively).  That determines
| the kind of completion to be used by the per-mode cycling keys.
| 
| This option controls which completion mode to use if you cycle using a
| per-mode key (e.g. `down') *before* hitting a completion key.
| 
|  - `prefix'  means cycle prefix completions
|  - `apropos' means cycle apropos completions
|  - Any other non-nil value means cycle inputs from the input history
|  - nil means do not cycle - you must first hit a completion key
| 
| The per-mode cycling keys are the values of
| `icicle-modal-cycle-up-keys' (backward) and
| `icicle-modal-cycle-down-keys' (forward).  By default, these are keys
| `up' and `down' as well as the mouse wheel.
| 
| For example, if the value is `prefix' (the default) then you can
| immediately cycle prefix completions using `up', `down', or the mouse
| wheel, without first hitting `TAB'.
| 
| Once you have used `TAB' or `S-TAB', the only way to traverse the
| history is using `M-p' and `M-n' (they always traverse the history).
| 
| This option affects only cycling with the per-mode keys.  You can
| always use the mode-specific cycling keys instead to cycle according
| to a particular mode.  The mode-specific keys are (by default):
| 
|  - `end'  and `home'  for prefix completion
|  - `next' and `prior' for apropos completion
| 
| (By default there is no conflict between the cycling keys that are
| mode-specific and those that are per-mode.  But if you customize them
| in such a way that you set a key to both, the mode-specific use takes
| priority.)
| 
| After you change the value of this option, toggle Icicle mode off,
| then on again, for the change to take effect in the same session.
| 
| You can customize this variable.
`----

RE: Icicles [was: shell command completion gone]

[Drew Adams]

> The doc string on this variable explains it pretty well, no?
>
> Setting icicle-default-cycling-mode to t was my first icicles
> customization.

To be clear: It has no effect on history cycling, once you've
hit `TAB' or `S-TAB'.  So it does not do what Rustom wants, IIUC.

If you want `up' and `down' to always cycle the history, then customize
`icicle-modal-cycle-up-keys' and `icicle-modal-cycle-down-keys'.

You do not need to _also_ customize `icicle-default-cycling-mode'.  Once you've
said that `up' and `down' will not perform per-mode candidate cycling, their
traditional behaviors of cycling the history kick in again.  They then _always_
cycle the history.

If, e.g., you choose `kp-1' for modal cycling down and `kp-7' for modal cycling
up, then using those keys before you hit `TAB' or `S-TAB' cycles according to
`icicle-default-cycling-mode', which is `prefix' by default.

Which is probably what you want, even when you have reestablished `up|down' for
history cycling.