IciclesIssuesClosed

iciclesimage
Previous: IciclesIssuesIciclesIciclesIssuesOpenIciclesIssuesStale

Closed Icicles Issues

This page is a record of closed issues), including bugs, reported by users of library icicles.el (Icicles): issues that were resolved (bugs that were fixed) and explanations of non-bugs.

See also:

Issues from IciclesIssuesOpen and IciclesIssuesStale are moved here when they are resolved.

How To Use This Page

For readability, please separate each issue thread with ‘----’ (horizontal line), and introduce each entry within a thread with `[new]’.

Better yet, use this to separate threads (puts space before and after the horizontal line):

 <pre>
 </pre>
 ----
 <pre>
 </pre>

(Closed) Issues



describe-face with icicles loaded results in an error:

Emacs version: GNU Emacs 24.3.1 on Linux

  (add-to-list 'load-path "~/.emacs.d/elpa/icicles-20140822.1645" t)
  (require 'icicles)

M-x describe-face

  Debugger entered--Lisp error:
  (wrong-number-of-arguments #[nil "..." 
    [faceprop face get-char-property read-face-name default keywordp
     (foreground-color background-color) nil facep] 4 1844164] 1)
    face-at-point(t)
    (or (face-at-point t) (quote default))
    (if (> emacs-major-version 23) (or (face-at-point t) (quote default)) "= `default' face")
    (read-face-name "Describe face"
      (if (> emacs-major-version 23) (or (face-at-point t) (quote default))
      "= `default' face") (not icicle-WYSIWYG-Completions-flag))
  ...

JohnPertwee

Should be OK now. Please try the latest icicles-mode.el. The arity of vanilla function ‘face-at-point’ changed between Emacs 24.3 and 24.4. Thanks for the report. – DrewAdams


How to disable the hide common match in Completion feature ? I’ve put the (setq icicle-hide-common-match-in-Completions-flag nil) in my init file and using for example ‘icicle-recent-file’…, but in fact it is not turned off. – JohnDoe974

See Expanded-Common-Match Completion for how to control the behavior. – DrewAdams

Ok Thanks! This behaviour looks recent to me.

After some digging I’m ending up disabling all of them using

(mapcar (lambda(x) (put x 'icicle-hide-common-match nil))
        '(icicle-find-file-abs-no-search
          icicle-find-file-abs-no-search-other-window
          icicle-find-file-abs-read-only
          icicle-find-file-abs-read-only-other-window
          icicle-find-file-abs-of-content
          icicle-find-file-abs-of-content-other-window
          icicle-recent-file-of-content
          icicle-recent-file-of-content-other-window
          icicle-locate-file-of-content
          icicle-locate-file-of-content-other-window
          icicle-locate-of-content
          icicle-locate-of-content-other-window
          icicle-locate-file-of-content-no-symlinks
          icicle-locate-file-of-content-no-symlinks-other-window
          icicle-recent-file-no-search
          icicle-recent-file-no-search-other-window
          icicle-locate-file-no-search
          icicle-locate-file-no-search-other-window
          icicle-locate-no-search
          icicle-locate-no-search-other-window
          icicle-locate-file-no-search-no-symlinks
          icicle-locate-file-no-search-no-symlinks
          icicle-find-file-absolute
          icicle-find-file-absolute-other-window
          icicle-recent-file
          icicle-recent-file-other-window
          icicle-locate-file
          icicle-locate-file-other-window
          icicle-locate-file-no-symlinks
          icicle-locate-file-no-symlinks-other-window
          icicle-locate
          icicle-locate-other-window))

JohnDoe974

1. Yes, it is a new feature.

2. You do understand that you can just do `C-x .’ to toggle it, right?

3. I can understand perhaps wanting it off by default for ‘icicle-recent-file’, since the recent files can be from anywhere (although as soon as you type something the candidates are typically limited to similar names). But for the others the initial set of file names typically share some common prefix, and often a long one.

4. Anyway, you’ve got the idea now.

DrewAdams (P.S. I simplified your code slightly.)


I’ve just recently updated to latest icicles (from Oct 6 13 versions) but now using ‘C-x f’ for recent file history always ask me for gpg files password and /ssh:localhost password. I ‘ve tried deleting the file from history list (using ‘M-i’) but cannot find them. Also I set ‘icicle-test-for-remote-files-flag’ to nil in my .emacs but no changes. Any idea whats happening ? Thanks.

From Oct 6? That is pretty old. Where are you getting the files from?

Anyway, I’m sorry I probably can’t help much with this. If you want to email me I can perhaps walk you through some debugging checks. It sounds like you are getting interference from Tramp (wrt remote file names): it sees that you are trying to access a remote file, so it asks for your password for the remote host etc.

Be sure to set and save option ‘recentf-exclude’, specifying remote hosts you use, so they are excluded. Check that ‘recentf-keep’ does not include any remote file names. Edit your ‘recentf-save-file’ to remove any remote file names.

And of course, try, as a start, to use Emacs without ‘recentf-mode’.

We’ve had problems with this kind of Tramp thing in the past, but I thought they were all worked out. I’m no expert on this. Send me an email with as much relevant info as you can, including Tramp version and Emacs version, platform, etc.

See also the various Tramp variables that can help with debugging (e.g., ‘tramp-verbose’: increase it). We will likely need to bring Michael Albinus (author of Tramp) into the mail exchange.

Try first to remove everything else from the equation. Get rid of your recentf file history and anything that is persistent (Desktop file etc., bookmarks file etc.), which might have recorded a remote file name.

That’s the first step: purge your environment of any such remote file names. Once that is done, we can try purposefully using a remote file name in a controlled way, to see what can be done.

Make backup copies of any such files, of course. Try testing by starting from ‘emacs -Q’ (no init file), and then loading only Icicles. Eliminate as much as possible that is extraneous to the problem. – DrewAdams

Drew, Thanks for your reply. I managed to solve the issue by deleting all reference to any remote file in my ‘recentf-save-file’ file. Somehow after deleting the lines in the file, I had to execute `(setq recentf …’ part so that changes are not overwritten when exiting emacs. I guess this is one drawback of setting history length to 200.

However I could not find any reference to any gpg file in my history but this is also gone and Icicles is not asking for the password when using ‘C-x f’. All Good ! Thanks again. – JohnDoe974

Phew! Glad it was so simple. I was worried that perhaps there were new changes to Tramp and I would need to figure out how to adapt again. – DrewAdams


First of all, HUGE Thanks for creating Icicles! I’am enjoying it everyday. Using Icicles ‘C-x C-f’ to open files, if I decide to create a new directory on the fly using `C-c +’ I will not be able to create a new file in the new directory I created. Here’s the step I take:

 1. `C-x C-f' 
 2. `C-c +'  to create a new directory "test" (select `yes')
 3. select "test" as directory in the minibuffer
 4. enter "newfile.txt"  ------------->>>  after hitting `Enter' Icicles complains "No Completion" and won't create the new file.

The workaround is to exit minibuffer and start again with ‘C-x C-f’. Is this a normal behavior or am I missing something ? – JohnDoe974

It was a bug. I think it is fixed now. Please try the latest icicles-mcmd.el. Thanks for the report. – DrewAdams

Thanks for the update. Still have the issue with the steps I described above. However If I hit ‘Enter’ between step 2 and 3, I can create any file.

OK, let’s see if I got it right this time. Please try the latest icicles-mcmd.el. Let me know, please – DrewAdams

Yes looks good to me! Thanks a lot ! – JohnDoe974


System: Windows 7

Emacs: GNU Emacs 24.2.1 (i386-mingw-nt6.1.7601)

Icicles Update #: 10597 (downloaded 2014-02-07 from wiki)

Hi,

I have a problem with `icicle-find-file-expand-directory-flag. Setting it to non-nil has no effect for me. (This variable did not exist in my previous version of Icicles, which is the reason I downloaded the newer version today).

steps to reproduce (for me, at least):

1. ‘C-x C-f’ (icicle-file)

2. cycling through directories with completion or apropos-completion

3. hitting Return upon selection of correct directory

This will always result in visiting the directory with dired, regardless of whether `icicle-find-file-expand-directory-flag is set to nil or non-nil. Hitting ‘C-x /’ while in minibuffer results in the message “Expanding directory candidates when you act on them is ON” (resp. OFF), but again, that doesn’t actually change behaviour, acting on directory candidates will always throw me to dired.

‘C-e’ and ‘C-M-/’ work correctly.

According to the documentation, this setting this option to non-nil results in “The effect of ‘RET’ and ‘C-RET’ is then the same as ‘C-M-/’”. But that is not the case for me.

Kind regards, Bernhard

I believe this is fixed now (2014-02-08). Thanks for the report. It was indeed a bug. – DrewAdams

Thanks for the quick response, it is indeed fixed now. – Bernhard


system: Ubuntu 12.04.1 LTS

emacs: GNU Emacs 24.2.1 (x86_64-pc-linux-gnu, GTK+ Version 2.24.10) of 2012-11-09 on lakoocha, modified by Debian.

icicles update: Update #: 9921

problem:

Emacs suggest some sane default buffer to switch to when performing “C-x b”. It places default choice into parentheses. You may switch to it just hitting Enter. It’s very convenient and I’d like to keep this behavior while using icicles.

step to reproduce:

1. Start emacs with icicles in the .emacs file

2. Visit a file (say “a.txt”)

3. Split windows (with “C-x 2” or “C-x 3”)

4. Visit another file (say “b.txt”)

5. Try to switch buffer with “C-x b”

what I see: “a.txt” what I need: “scratch

I need to ignore visible buffers when calculating default choice for buffer switching – AvangoAtZoho

Please try the latest icicles-cmd1.el. Thx – DrewAdams

I’ve checked icicles-cmd1.el version 25681 (chg version 9926). It works! Thx – Ayvango


Hi Brian. During commands that read buffer-name input, ‘C-x v -’ removes buffers that are visible (and `C-x v +’ removes those that are invisible).

However, although there has been a prefix arg possibility (namely ‘C-u C-u’) that gives you only visible buffers as candidates (and as default values), there has not been one that gives you only invisible buffers. I’ve just added that now, so you should be able to do ‘C-u C-u C-u C-x b’ to get what you want.

You can also easily create a command that does only that, so you don’t have to hit ‘C-u C-u C-u’ if you use this behavior a lot. (Just ‘let’-bind ‘current-prefix-arg’ as you like and call ‘icicle-buffer’.)

I suppose a user option would also be possible, but I’m not sure what the best form for that would be. One thing that might be helpful would be to let users choose which prefix arg forms give which behaviors — today that matchup is hard-coded.

I don’t have any plans to add an option for something like this, but I’m always open to considering suggestions. In the meantime, try ‘C-u C-u C-u’, or try using ‘C-x v -’ to filter on the fly.

Another thing you can do is to simply set option ‘icicle-buffer-predicate’ to a predicate that excludes visible buffers. I think most users will not want to use an option such as this or the one you suggested, because it is a blanket that covers all buffer-name completion.

Another possibility is to dissociate the selectivity for default values (accessible via ‘M-n’) from that for completion candidates. Today they both follow the prefix argument form the same way.

I mention that because you asked about default values, not about completion candidates. Dunno whether that means that you would like all buffers as candidates but only invisible ones as default values?

Thx – DrewAdams

I just added two user options that I think might help:

  • `icicle-buffer-prefix-arg-filtering’, which controls the prefix argument behavior. So, for instance, if you want lack of a prefix arg to mean use only invisible buffers and ‘C-u C-u C-u’ to mean use all buffers, you can easily have that behavior. You can define any prefix-arg tests you want, with any corresponding filter behaviors you want.
  • `icicle-buffer-candidate-key-bindings’, which defines the key bindings to use for on-the-fly filtering (narrowing).

I think this should offer you the flexibility you seek. HTH – DrewAdams


C-x m is normally bound to compose-mail by emacs (in simple.el). When I use icicles and bookmark+ alone, it works for me as documented here. But with my normal .emacs, it doesn’t: I get a new mail buffer. That’s true even when I load both at the very end of my .emacs. How can I fix this? E.g. track down where the conflict comes up, or what to add to my .emacs to re-bind it for use with bookmarks? – NealMcBurnett

Sounds like somehow your .emacs or something it loads is binding ‘C-x m’ in a minibuffer keymap (which map depends on your Emacs release).

For example, with Emacs 24, the map that should contain ‘C-x m’ as ‘icicle-bookmark-file-other-window’ is ‘minibuffer-local-filename-completion-map’. In Icicle mode, if you do ‘C-h v’ and enter that keymap name then you should see this in the keymap value: (24 keymap (97) (109)). The 24 is ‘C-x’ and the 109 is ‘m’.

As with all problems where you have no idea what the culprit is, bisect your init file, by commenting out half of it. Then bisect the problematic half, then the problematic quarter,… This binary search is very quick. You will locate the problem in no time. – DrewAdams

Thanks for the quick response. Sorry for leaving out even basic version info: I’m using the Emacs on Ubuntu Precise 12.04: GNU Emacs 23.3.1 (x86_64-pc-linux-gnu, GTK+ Version 2.24.10), and the icicles package in precise: 23.0+20110910-1, and the bookmark+ version from quodlibetor/bookmarkplus-github https://github.com/quodlibetor/bookmarkplus-github/.

And thanks again for all this cool code! Though I’ll chime in with the frustration that you don’t use or endorse any effective version control or version numbering or packaging scheme for all this code. It pains me to follow the instructions here, but here goes for the ‘version’ I’m using:

$ grep 'Update #' *
col-highlight.el:;;     Update #: 320
crosshairs.el:;;     Update #: 404
hexrgb.el:;;     Update #: 782
hl-line+.el:;;     Update #: 434
icicles-chg.el:;;     Update #: 7120
icicles-cmd1.el:;;     Update #: 22215
icicles-cmd1.el:Each Icicles file has a header `Update #' that you can use to identify it.\
Binary file icicles-cmd1.elc matches
icicles-cmd2.el:;;     Update #: 4206
icicles-doc1.el:;;     Update #: 26186
icicles-doc2.el:;;     Update #: 28228
icicles.el:;;     Update #: 22978
icicles-face.el:;;     Update #: 574
icicles-fn.el:;;     Update #: 12563
icicles-mac.el:;;     Update #: 813
icicles-mcmd.el:;;     Update #: 17246
icicles-mode.el:;;     Update #: 7595
icicles-opt.el:;;     Update #: 4465
icicles-var.el:;;     Update #: 1538
icomplete+.el:;;     Update #: 931
lacarte.el:;;     Update #: 638


bookmark+-1.el:;;     Update #: 5539
bookmark+-1.el:Be sure to mention the `Update #' from header of the particular Bookmark+ file header.\
bookmark+-bmu.el:;;     Update #: 2047
bookmark+-chg.el:;;     Update #: 14933
bookmark+-doc.el:;;     Update #: 14564
bookmark+.el:;;     Update #: 14985
bookmark+-key.el:;;     Update #: 564
bookmark+-lit.el:;;     Update #: 779
bookmark+-mac.el:;;     Update #: 97

Upon further searching, I find that it is different than the one at https://github.com/emacsmirror/bookmark-plus. Sigh.

I had found that minibuffer-local-filename-completion-map keymap, and it looks much like you say:

 (24 keymap
     (109)
     (77)
     (116 . icicle-cycle-image-file-thumbnail)
     (46 . icicle-dispatch-C-x\.)
     keymap
     (6 . icicle-resolve-file-name))

I was puzzled about why there was no function bound in “(109)”. At any rate, it looks the same both with and without my .emacs, but one works and the other doesn’t, which just increased my confusion factor. A bit of flipping thru the info pages on keymap didn’t help. What’s going on? And how can I just set it to the right thing, ignoring whatever is going on in my .emacs? – NealMcBurnett

IIUC, it works OK for you from emacs -Q but not when your .emacs is loaded. You will need to do what I suggested above, in my last paragraph: recursively bisect your .emacs to find out what part of it is making the difference.

I was mistaken about what I said about checking minibuffer keymaps. The reason you (and I) do not see a non-empty binding for 109 is that the binding is in fact created on the fly in Icicles file-manipulation commands, such as ‘icicle-file’. If you are curious, you can do ‘M-x debug-on-entry icicle-bind-file-candidate-keys’ and then step through the debugger to see it bind ‘C-x m’ properly.

But it seems clear that something in your .emacs is interfering with that binding. You need to find out what. As I said, a binary search of your .emacs is surprisingly quick, no matter how much code (e.g. libraries) you use. - DrewAdams

Aha - that’s the issue - that it changes dynamically. I didn’t find any good google hits on an efficient process to do bisection on a .emacs, especially given the advice for icicles that we’re supposed to load it after loading most of the rest of the .emacs. So I just gave up on that aspect and fiddled with emacs -q .emacs and eval-region for a while, and ran across the culprit: (ffap-bindings).

I found where you talk about those issues at Icicles - Inserting Text from Cursor but I suggest you clarify that dynamic binding in places like Icicles - File-Name Input as part of the text Note: In addition to the usual Icicles key bindings, during file-name completion you can use the following keys. (These minibuffer bindings are also available for autofile bookmark commands.) Thanks again – NealMcBurnett

1. Glad to hear that you found (and presumably solved) your problem.

2. When I recommend recursively bisecting your init file I do not mean that you must bisect literally (exactly 50%) or completely blindly. The point is to narrow things down in a systematic way, dividing the search domain roughly in half each time.

If you can or must evaluate some particular code each time, IOW, not include it as part of the search space, that’s fine. Use your judgment to determine the space to be searched. Within that space you can apply the idea of subdivision. That’s all.

3. I don’t know what you have in mind wrt “clarify that dynamic binding in places like Icicles - File-Name Input”. Can you elaborate? What do you think would be helpful to add? – DrewAdams

The issue is that you make it clear most of icicles is generic for most completion functions, but the stuff described here is specific to certain ways of getting to completion. So I mean that the File-Name Input article should clarify, as part of the sentence I quoted or at least nearby the list of bindings, that they are dynamicly added bindings which you only get if you run a certain icicle function (or two?). And that you only get that/those functions bound to file-finding keybindings like c-x c-f if icicles is initialized with those bindings pointing to a particular canonical emacs function, so stuff like ffap can mysteriously get in the way. – NealMcBurnett

Got it, I think. See if the doc changes I made help. Let me know if you have further suggestions. Thx – DrewAdams


I’ve found another little bug: when i go to another machine with tramp, like `/ssh:pasja@example.com:/pasja’ and hit the famous tab key, the machine part goes to the completion. My prompt looks like `/ssh:pasja@example.com:/pasja/pasja@example.com’. Of course this directory does not exist in my home folder, and i have to delete back, to get the real completion. After that is could use it normally.

Regards– PasJa

What Emacs version are you using, and what Tramp version? – DrewAdams

Emacs: GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0) of 2010-12-11 on raven, modified by Debian

Tramp: 2.1.18-23.2

PasJa

I cannot repro it on Windows. MichaelHeerdegen tried but cannot repro it on GNU/Linux. Please follow up using email. Thx – DrewAdams

[PasJa:2014-01-07]

Today i’ve restarted my emacs(it run more than half year 😊 and upgraded icicles to the current version. The problem which i described above is gone.

Regards --PasJa

Thanks for thinking of updating this report, PasJa. – DrewAdams


Hi Drew!

Iv’got another icicles issue: If i hit ‘C-x C-f’ to open files, and i go back to the directory tree with ‘C-backspace’ (icicle-up-directory) every time i reach the ‘/’ character, a message pops up in the minibuffer: “Tramp: Waiting for prompts from remote shell” and emacs freezes, after the process timed out, emacs responds again.

My tramp config(nothing special)

   (setq shell-prompt-pattern "^[^a-zA-Z].*[~#$%>] *" ; we need a bit more funky pattern, as tramp will start $SHELL (sudo -s), ie., zsh for root user
         tramp-default-method "ssh"
         tramp-persistency-file-name "~/.emacs.d/cache/tramp")

Regards, PasJa

Hi PasJa,

Send me a mail with this info, and cc MichaelAlbinus (michael.albinus AT gmx.de), who writes Tramp.

A workaround is perhaps to use `C-#’ in the minibuffer to turn off incremental completion. No doubt, when Icicles tries to complete ‘/’ Tramp is kicking in for some reason and trying to complete that string first.

Another possible workaround is to use `C-^’ in the minibuffer to toggle remote-file testing (it toggles option ‘icicle-test-for-remote-files-flag’), which also turns off Tramp’s completion. Toggle it back on when you want that completion.

Hopefully Michael will have an answer for us. But you need to specify exactly which OS you use, which Emacs version, which Tramp version, and any customizations — preferably provide a recipe from emacs -Q that specifies only the customizations needed to reproduce the problem. Thx – DrewAdams

I think the problem is fixed now. Please try the latest files and let me know. I could not test this on Windows – there is no problem there, because / is automatically expanded to c:/ or whatever, which prevents Tramp from kicking in. But MichaelAlbinus was kind enough to debug it and found the problem. It was not at all in the completion code but in was in a little function that displays info about the current candidate in the mode line.

Please give it a try and let me know. Thx – DrewAdams

Hi Drew,,

Thanks, both of you, i tried the latest version, now it is usable. I’ve got some long living tramp connection now 😊

Regards– PasJa


Hi Drew!

I found a bug in the latest icicles(Update #: 5280 in icicles-cmd2.el). When i hit ‘C-c / ’ icicle-complete-thesaurus-entry then i’ve got a Symbol’s function definition is void: icicle-complete-thesaurus-entry error.

I’ve opened icicles-cmd2.el and eval-ed the defun with ‘C-M-x’ but the error remains.

May i suggest to you that you should free the ‘C-c / ’ bindig. OrgMode uses it heavily, i’ve discovered the bug in org-mode when i’ve tried http://orgmode.org/org.html#Sparse-trees

Regards, PasJa

Hi PasJa. There are a couple of things to say about this.

1. Thanks for your report. Should be fixed now. The error came from the default value of ‘icicle-top-level-key-bindings’, which was unconditionally binding the key instead of binding it only if the command is defined.

2. After the fix, if you do not use synonyms.el then the key will not be bound by default.

3. Even if you do use synonyms.el, it is trivial to prevent the key binding: just customize option ‘icicle-top-level-key-bindings’. That’s why it is a user option.

4. Wrt Icicles using (by default) the binding ‘C-c /’, and the conflict with OrgMode:

Icicle mode is a minor mode. IIUC, OrgMode is a major mode. Per the Elisp manual (Key Binding Conventions):

  • Sequences consisting of C-c followed by {, }, <, >, : or ; are also reserved for major modes.
  • Sequences consisting of C-c followed by any other punctuation character are allocated for minor modes. Using them in a major mode is not absolutely prohibited, but if you do that, the major mode binding may be shadowed from time to time by minor modes.

IOW, it is OrgMode, not Icicles, that is not behaving well here. More precisely, it is not behaving badly, but it must expect that minor modes such as Icicle mode will overwrite such a key binding. (Of course, Icicles only overwrites it by default, and only if you also use library synonyms.el.)

Thx – DrewAdams


Hi Drew, You made a small mistake and uploaded icicles-chg.el as icicles-mac.el, so icicles stopped working for me 😊

Another, completely different issue:

I use: GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0) of 2010-12-11 on raven, modified by Debian and icicles latest version.

The historical candidates feature stopped working for files. Actually M-h works fine, but M-Pause stopped working, only for files. I use savehist to save icicle-previous-raw-file-name-inputs and icicle-previous-raw-non-file-name-inputs variables, if it matters something. Please notice me here if you need more precise describe of the problem. – PasJa

Sorry about that – icicles-mac.el should be OK now.

Make sure that you (a) load icicles-mac.el, (b) byte-compile icicles-mac.el (if you byte-compile files – recommended), then (c) byte-compile all of the other Icicles files. It is important to re-byte-compile all files after loading icicles-mac.el, whenever icicles-mac.el has changed.

Dunno about your problem with using ‘M-pause’ with file-name reading. It works fine for me, with all Emacs versions through a Sept 19 build of Emacs 24 (the latest build I have). Be sure that you have used ‘TAB’ or ‘S-TAB’ before you hit ‘M-pause’ (or a message will tell you to).

You can try ‘M-x debug-on-entry icicle-keep-only-past-inputs’, perhaps (after loading icicles-mcmd.el – not the .elc). The main thing to check when doint that is the value of the value of ‘minibuffer-history-variable’ (which should itself be ‘file-name-history’). Let me know what you find out. (Of course, without the correct latest icicles-mac.el, nothing should work well at all.) Thx – Drew

Hi Drew,

I set up a testing enviroment and i’ve got some more strange errors:

a.) test init.el

    (setq debug-on-error 1)
    (add-to-list 'load-path "/tmp/.emacs.d/") ; start emacs with HOME=/tmp, do not clobber my prod setup

b. content of “tmp.emacs.d/” …

 M-x load library RET icicles RET

Then:

   require(icicles-var)
    Debugger entered--Lisp error: (void-function incf)

… I’ve stopped here. If we could solve this problem, i will continue to investigate the previous problem. --PasJa

My bad. I made some substantial changes recently that moved things around a bit. I moved some things to icicles-mac.el and that meant that that file needed to require cl.el[c] when byte-compiling. This should be OK now. Please load the latest version of that file, byte-compile all of the Icicles files (if you use them byte-compiled, which I recommend), then restart Emacs. Sorry for the trouble. Thx – DrewAdams

So, icicles loading correctly. I use the ‘canonical’ method to load icicles. My init.el:

    (add-to-list 'load-path "/tmp/.emacs.d/")
    (require 'icicles)
    (icy-mode 1)

Icicles has been downloaded today. Content of tmp.emacs.d/

    -rw-rw-r-- 1 pasja pasja 491787 Oct 12 15:16 icicles-chg.el
    -rw-rw-r-- 1 pasja pasja 359710 Oct 10 23:19 icicles-cmd1.el
    -rw-rw-r-- 1 pasja pasja 408344 Oct 10 23:38 icicles-cmd2.el
    -rw-rw-r-- 1 pasja pasja 359098 Oct  9 17:15 icicles-doc1.el
    -rw-rw-r-- 1 pasja pasja 459966 Oct  9 19:46 icicles-doc2.el
    -rw-rw-r-- 1 pasja pasja  70167 Oct 12 18:09 icicles.el
    -rw-rw-r-- 1 pasja pasja  34134 Oct 11 00:27 icicles-face.el
    -rw-rw-r-- 1 pasja pasja 366856 Oct 10 23:00 icicles-fn.el
    -rw-rw-r-- 1 pasja pasja  59985 Oct 12 18:08 icicles-mac.el
    -rw-rw-r-- 1 pasja pasja 408090 Oct  9 03:41 icicles-mcmd.el
    -rw-rw-r-- 1 pasja pasja 271907 Oct  9 03:39 icicles-mode.el
    -rw-rw-r-- 1 pasja pasja 191423 Oct 10 22:48 icicles-opt.el
    -rw-rw-r-- 1 pasja pasja  76484 Oct  8 19:15 icicles-var.el
    -rw-rw-r-- 1 pasja pasja     97 Oct 13 12:32 init.el

Turned on ‘debug-on-entry icicle-keep-only-past-inputs’ The debug output is a little overwhelming 😊 I checked the values with ‘C-h v’

minibuffer-history-variable value is file-name-history

file-name-history value is (”~/.emacs.d/icicles-face.el” “~/.emacs.d/icicles-doc1.el” “~/.emacs.d/icicles-chg.el”)

I noticed that when i hit S-Tab or Tab the face (blue by default) is not set correctly, so maybe the problem lies somwhere else. In the variables it displays correctly in blue and M-Pause works correctly.

Another question:

Why bind this function to M-Pause. They have been placed far from each other on the keyboard. Yeah, i could rebind it, but i try to understand the motivation. --PasJa

I don’t know what you mean by “In the variables it displays correctly in blue and M-Pause works correctly.”, but maybe it’s not important.

Check the variable values in the debugger, using ‘e’, not just outside using ‘C-h v’. If you want, you can step through the debugger (‘d’ to step, ‘c’ to skip over a step (evaluate it completely)), to see what happens.

For Icicles, I believe there should be nothing special about file-name completion that would make ‘M-pause’ work in general but not for file names.

Dunno what to suggest. (I assume that you used ‘TAB’ or ‘S-TAB’ prior to hitting ‘M-pause’. I assume that you have used ‘C-pause’ once or twice to be sure that past-entry highlighting is turned on.)

Try removing those variables from savehist, to take savehist out of the equation. Perhaps try clearing the history (e.g. ‘M-i’) and starting over, entering some file names (using ‘RET’) etc.

The choice of ‘M-pause’ was nothing special, IIRC. Lots of the Icicles default choices for keys were based on things like (a) associations, including with historical Emacs defaults, (b) key placement, (c) whether the key needs to be repeatable by holding it down, (d) mnemonic aid, (e) relations to other keys (e.g. ‘RET’, ‘C-RET’, ‘C-M-RET’, ‘S-RET’…). But I don’t recall any special logic behind the choice of ‘M-pause’.

You can email me, if you like. It would probably be easier to dialog that way about your problem. Sorry for your trouble. – DrewAdams

Hi Drew! If i understood correctly, ‘icicle-keep-only-past-inputs’ is just some kind of filter function. And if the files don’t have the marking opened before, the filter function does not work. That was what i tried to describe.

Used my test enviroment, what i’ve described before. I’ve already taken out ‘savehist’ and i’ve hit ‘C-Pause’ many times. But, if i hit ‘M-i’ i see the previous files!! Thanks for the explanation about your key choiches! I’ve uploaded some screenshots: MetaI MetaPause I will mess the debugger later… – PasJa

I think you’re saying that ‘file-name-history’ is correct, but that ‘M-pause’ does not restrict the current set of candidates to just names that are in ‘file-name-history’. From your screenshots I see that, but I also see that there is no highlighting (blue) of any history candidates in your MetaPause screenshot, whereas all history candidates (hence all candidates showing after ‘M-pause’) should be highlighted.

(There is also no alignment of candidates, but I don’t know if that indicates anything here. Maybe this is because of your settings of ‘icicle-candidate-width-factor’ and ‘icicle-inter-candidates-min-spaces’.)

I cannot reproduce the problem – I see history highlighting, and ‘M-pause’ immediately filters the current set of candidates to only those that are also history candidates (which all appear blue).

You will need to provide a complete recipe, I guess, starting preferably from emacs -Q. (I assume that you first hit ‘TAB’ or ‘S-TAB’ before hitting ‘M-pause’. If not, please see the doc.) I will try to reproduce the problem if you can give me more info (a recipe) – so far, I cannot repro it. Sorry. I’ve tested with the first Emacs 24 pretest, Emacs 23, 22, and 20 (on Windows). – DrewAdams

OK, i will give you the complete recipe. --PasJa

Any news on this? – DrewAdams

Sorry, i have a busy IRL period. I try to get some time to debug this issue.

Hi Drew! I think i found the issue: if i open something in my home directory ($HOME in linux) then ‘M-pause’ does not work. But if i open something else ex.: /tmp/test.txt then it works correctly! Maybe you should start search the problem around the ‘~/’ vs. absolute notation/highlighting/searching. There should be some difference in windows or icicles path handling, that prevents this issue. Screenshots: TmP TmpMetapause --PasJa

Thanks for hanging in there, PasJa. Sorry for your trouble. I can’t reproduce this at my end, but I’m using Windows. I suggest you do this (temporarily), in the code of ‘icicle-keep-only-past-inputs’:

Just after this line:

  (when (consp (symbol-value minibuffer-history-variable))

Add this line:

  (message "hist: %S" minibuffer-history-variable)

In this part of the code:

  (lambda (candidate)
    (when (icicle-file-name-input-p)
      (setq candidate  (expand-file-name
                        candidate
                        (icicle-file-name-directory
                         icicle-last-input))))
    (member candidate
            (symbol-value minibuffer-history-variable)))

Just before the ‘when’ line, add this:

   (message "111, cand: %S" candidate)

Just before the ‘member’ line, add this:

   (message "222, cand: %S" candidate)

Then evaluate the modified definition of ‘icicle-keep-only-past-inputs’ (e.g. ‘C-M-x’ inside the definition).

The try your recipe again, but preferably in a directory that doesn’t have too many files and subdirs (so it’s easier to read the output). The messages will be written to buffer ‘*Messages*’. Show that buffer (e.g. in a separate frame, with ‘C-x 5 b’) before following your recipe, and put the cursor at the buffer end to begin with.

What is printed to ‘*Messages*’ should show you (a) what the candidate files names look like, versus (b) what the history entries look like. The ‘111’ and ‘222’ lines for a given candidate show how the raw candidate is transformed to be compared with a history element. You will presumably see that a transformed candidate that should correspond to a history element does not have the right form (the two are compared as plain strings, so they need to match exactly).

Do this in both a directory where ‘M-pause’ works and in one where it does not work. Let me know what you find. Thx – DrewAdams

Hi Drew! Modified ‘icicle-keep-only-past-inputs’: ModIcMP Where it does not works: my home directory($HOME) is ‘/root/’ it has a sub directory ‘1’ and has 3 files ‘a’,’b’,’c’

    root
    └── 1
        ├── a
        ├── b
        └── c

Content of the ‘*Messages*’ buffer, after i open /root/1/a,/root/1/b,/root/1/c:

    hist: file-name-history
    111, cand: "a"
    222, cand: "/root/1/a"
    111, cand: "b"
    222, cand: "/root/1/b"
    111, cand: "c"
    222, cand: "/root/1/c"

Where it works (similar setup):

    tmp
    ├── 2
        ├── a
        ├── b
        ├── c

Content of the ‘*Messages*’ buffer, after i open /tmp/2/a,/tmp/2/b,/tmp/2/c:

    hist: file-name-history
    111, cand: "a"
    222, cand: "/tmp/2/a"
    111, cand: "b"
    222, cand: "/tmp/2/b"
    111, cand: "c"
    222, cand: "/tmp/2/c"

So strange, there is no difference between the outputs…

If i modify my $HOME ex.: `$HOME=/tmp’ and i start emacs, than /tmp is bad and /root is good. – PasJa

Thanks for going to that trouble. This info is missing: the value of ‘file-name-history’. Can you please change

  (message "hist: %S" minibuffer-history-variable)

to

  (message "hist: %S" (symbol-value minibuffer-history-variable))

And see what that value looks like. Evidently, for some reason it has entries that match absolute file names except when the files are in your home dir. Most likely ‘file-name-history’ is showing home-dir files as ~/filename, for some reason. On Windows, it has only absolute file names, no ~/filename names, and this problem has not been reported before.

Please make this test and let me know. That will help me know the best way to fix this. Most likely I need to map over the history to ensure absolute names, but I’d like to see for sure what it looks like. No need to print the whole ‘file-name-history’ value – just enough to see how it represents files in both your home dir and other dirs. Thx – Drew.

Hello Drew! Updated version: ModIcMP I’ve created the same directory structure. Here is the output from the ‘*Messages*’ buffer:

from /tmp/2:

    Computing completion candidates... [3 times]
    hist: ("/tmp/2/b" "/tmp/2/a" "/tmp/2" "/tmp/")
    111, cand: "a"
    222, cand: "/tmp/2/a"
    111, cand: "b"
    222, cand: "/tmp/2/b"
    111, cand: "c"
    222, cand: "/tmp/2/c"

from /home/pasja/1 ($HOME=/home/pasja):

    Computing completion candidates... [4 times]
    hist: ("~/1/b" "~/1/a" "~/1" "~/" "/tmp/2/b" "/tmp/2/a" "/tmp/2" "/tmp/")
    111, cand: "a"
    222, cand: "/home/pasja/1/a"
    111, cand: "b"
    222, cand: "/home/pasja/1/b"
    111, cand: "c"
    222, cand: "/home/pasja/1/c"

PasJa

p.s.: Would you consider the use of an official, publicly accessible VCS. It’s a little hard to follow the actual code changes in icicles(not the changelog)

1. OK, thanks. That’s what I thought. I’ll take care of it, probably in a day or two.

2. (VCS) Nope, sorry. But ‘ediff’ is your friend, if you want to compare versions of a particular file. – DrewAdams

OK, I’ve uploaded a fix – please let me know how it goes.

FYI, here’s the story: The Emacs history lists record exactly the input you enter (e.g. using ‘RET’). Emacs itself never compares entries of this list. Icicles compares them against current candidates for two purposes: (1) highlighting with face ‘icicle-historical-candidate’ and (2) ‘M-pause’ (‘icicle-keep-only-past-inputs’).

Until now, the comparison was literal, including for file names. If you enter “~foo/bar.el” then exactly that string is recorded in the history. Candidates that are later compared against the history are expanded in the current directory, to become absolute file names (e.g. “/home/foo/bar.el”). The matching is literal, syntactic.

I’ve now enhanced this to try to accommodate input entries such as “~foo/bar.el”, by expanding not only the current set of candidates but also everything in the history list (for only this purpose – the list itself is not changed). Obviously, this can mean a performance hit. If there is a long history list and there are lots of current candidates, the slowdown from this file-name expansion might be noticeable.

Anyway, it should work now. Let me know. Thanks for your patience and your careful reporting. – DrewAdams

Hi Drew! Works perfectly! It can be moved to IciclesIssuesClosed I would like to hear your arguments against VCS! It’s a pleasure to work with such a responsive developer! Regards, --PasJa

Thanks for the report and your help debugging. I have no arguments against VCS; I simply prefer to use the wiki. There are some mirrors of some of my libraries (including Icicles) on various GIT etc. VCS sites here and there, and there will likely be more in the future. The latest source files are here on the wiki. Thx – DrewAdams


Hi Draw, I have a minor issue or feature request. Whenever I try to connect to a remote server via tramp and C-x C-f, icicles connects to the server to complete filenames etc. Is there any method to turn icicles off when I am entering a tramp path? Thank you – 85.181.227.84

Unfortunately, they change Tramp about every two minutes. ;-) What is fixed in one version is broken in the next, and vice versa.

In order to try to do anything about your problem, you will need to (a) state your Emacs version, (b) likewise your Tramp version (if not the one that came with your Emacs version), and (c) provide a complete, step-by-step recipe, starting from emacs -Q.

See also command ‘icicle-toggle-remote-file-testing’ (`C-^’ in minibuffer). But even if you end up using that to work around a problem, please report to me as much as you can about the Tramp problem you encounter. Please report by email, as it is much easier to correspond that way: ‘M-x icicle-send-bug-report’. Thx – DrewAdams

Nvm., I had set ‘icicle-highlight-input-completion-failure’ to ‘always’. Thank you for your help – 85.181.227.84

Dunno “nvm”, but I guess you’re saying that you no longer have a problem, after changing ‘icicle-highlight-input-completion-failure’ to something else. If so, let me know if you think it would help to modify the doc somewhere. I’ve moved this to IciclesIssuesClosed, assuming I understood correctly that it’s OK. – DrewAdams


Is there a binding to open an Icicles Occur from thing at point with one key? Thanks MikeF

Icicles occur (‘icicle-occur’, `C-'’) is not the same as ‘occur’. The regexp it uses is dynamic: whatever you type in the minibuffer immediately updates the “occur” matches. A “default value” has no meaning here. However, in Icicles you can always insert text that is at point into the minibuffer, using `M-.’. See Icicles - Inserting Text from Cursor.

I noticed Icicles Occur search is not re-started on execution of `M-.’ I was able to restart the search by using backspace then re-typing the last character. Is the non-restart purposeful? Is there a variable restart-after-thing-at-point-fetch, or a general command restart-search?--Thanks Mike

Sorry, I don’t follow. Please give me a clear, step by step recipe, preferably starting from emacs -Q, saying what you see and what different you expected to see. Each time you use `C-c '’ it should invoke ‘icicle-occur’.

`M-.’ does not invoke ‘icicle-occur’ – you can use it anytime in the minibuffer. What it does is insert some text in the minibuffer (what it inserts depends on the thing at point, how it is configured, and whether you use a prefix arg).

`M-.’ insertion is similar to having typed something in the minibuffer, but without incremental completion; that is, it does not automatically re-complete. (Perhaps that’s what you meant?) To complete what is in the minibuffer at any time, hit ‘S-TAB’ (or ‘TAB’) again.

You don’t really want `M-.’ to automatically re-complete after inserting, believe me. For one thing, it is very often repeated, and often to get alternative things at point. You don’t want completion against the wrong thing, and you don’t want to have to hurry to forestall automatic (i.e., incremental) completion. For another thing, it is very often the case that you want to edit the text that you pull into the minibuffer. You don’t want automatic completion of it before you get a chance to edit it.

What you really want, I think, is what Icicles does: you request completion when you want it. If you don’t trust me on this one, all you have to do is this, to try automatic re-completion after `M-.’:

  (defun icicle-insert-string-at-point-and-update (&optional arg)
    "Like `icicle-insert-string-at-point', but complete afterward."
    (interactive "P")
    (icicle-call-then-update-Completions
      #'icicle-insert-string-at-point arg))

Then replace ‘icicle-insert-string-at-point’ by that command in a copy of icicles-mode.el, load that, and toggle ‘icy-mode’ twice. Try it and you’ll see that it is not what you want. If it is, then now you know what to do to get it. ;-) – DrewAdams

Hi Drew, S-TAB does the trick. Thanks Mike


Hi Drew!

Some quick questions:

How to go to ‘*completions*’ buffer automatically when i hit TAB or S-TAB? Now i have to hit C-INS to go to the ‘*completions*’ buffer.

I cycling in the completions buffer and if i go through some directories, they’ve been cocatenated to the path. I vant the same behaviour as i’ve got for files (replace not concatenate).

Screenshot for clarification: http://imageshack.us/photo/my-images/833/icicles.png/

Thanks for your answer! --PasJa

1. I cannot get to the image you posted. Try posting the image on ThisWiki instead.

2. You should not need to go to (i.e., select) ‘*Completions*’. I almost never do that. What is the use case? Why not just cycle candidates using ‘down’ etc. from the minibuffer?

3. Give me a recipe to reproduce. I don’t understand what it is that you’re doing/seeing.

4. But I do see a bug, which I don’t have time now to look into: Yes, cycling when in ‘*Completions*’ appends directories. It should not do that. A workaround is to do your cycling from the minibuffer, as usual.

Thx – DrewAdams

1. CompBug

2. Use case for ‘*Completions*’ cycling: directory with maaaany files, i’ve want to select the 3rd row, 4th column file which has a long and ugly name which i don’t want to type. If i am in the ‘*Completions*’ i hit ‘*down*’ 3 times and ‘*right*’ four times and i am free of misspelling and other problems. Like if you use zsh and grml-zshrc

3. and 4. This is the bug!

Thx --PasJa

Yes, I already acknowledged the bug – directories should not be appended. I do not have a fix for it now. And I understand and recognize your use case – nothing wrong with doing that.

However, in general, it is better to privilege completion — in particular, progressive completion — than it is to privilege cycling (either in ‘*Completions*’ or using minibuffer keys).

There is nothing wrong with doing what you tried (but it is currently bugged), but in general you will want to get in the habit of using completion rather than cycling. In your example (and I do realize it was just a test case to communicate the problem), for instance, you can just type ‘c S-TAB’ (since only one candidate has the substring ‘c’).

Yes, cycling can sometimes be handy (no need to think about/recognize patterns), especially if there are few candidates. Yes, there is a bug wrt cycling in ‘*Completions*’. There are two workarounds/alternatives: completing instead and cycling from the minibuffer instead. – DrewAdams

That bug should be fixed now. Let me know if you still see a problem here. Thx – DrewAdams

Thanks, it works perfectly!

--PasJa


I’m using Icicles r181 on GNU Emacs 24.0.50.1 (i386-mingw-nt6.1.7601). When I run ‘M-x modify-face RET default RET’, it reads the name of the face, then throws up an error: Wrong type argument: listp, "System". This happens regardless of the actual face specified. As far as I can tell, the problem is in ‘icicle-face-valid-attribute-values’ (icicles-fn.el:1879) where the function uses the return value from ‘font-family-list’ as a list of conses, whereas in fact it’s a list of strings. – Aankhen

Thanks for the report. They changed ‘face-valid-attribute-values’. I updated to reflect the new definition. Should be OK now – let me know. – DrewAdams

Yup, it looks like that fixed it, thank you. BTW, is the git propagation automatic? It took quite a while before the change showed up, and it seemed to be clustered with several others. – Aankhen

I don’t really have anything to do with the git propagation; sorry. You could ask JonasBernoulli. I believe he is the one that makes that happen. – DrewAdams


 ;;bugs about icicle and autoload
(require 'autoload)
(setq source-directory "~/.emacs.d/site-lisp/")
(setq generated-autoload-file "joseph-loaddefs.el")
;;so there is a ~/.emacs.d/site-lisp/lisp/joseph-loaddefs.el now


;; now I run
(update-directory-autoloads "~/.emacs.d/site-lisp/icicles/") ;;all files about icicles are in this directory 
;;to update  `joseph-loaddefs.el' now.

;; now I load icicles
(add-to-list 'load-path "~/.emacs.d/site-lisp/icicles")

(add-to-list 'load-path "~/.emacs.d/site-lisp/lisp/")
;;add joseph-loaddefs require
(require 'joseph-loaddefs)

;;then I run  
(icy-mode)
;; I got 
;; Debugger entered--Lisp error: (void-function icicle-restore-standard-options)
;;   (icicle-restore-standard-options)
;;   (cond (icicle-mode (add-hook ... ...) (add-hook ... ...) (add-hook ... ...) (add-hook ... ... ...) (icicle-redefine-standard-options) (icicle-undo-std-completion-faces) (icicle-redefine-std-completion-fns)) (t (remove-hook ... ...) (remove-hook ... ...) (remove-hook ... ...) (remove-hook ... ...) (icicle-restore-standard-options) (icicle-restore-std-completion-fns)))
;;   (let ((last-message ...)) (setq icicle-mode (cond ... ... ...)) (cond (icicle-mode ... ... ... ... ... ... ...) (t ... ... ... ... ... ...)) (message "Turning %s Icicle mode..." (if icicle-mode "ON" "OFF")) (icicle-rebind-completion-maps icicle-mode) (message "Turning %s Icicle mode...done" (if icicle-mode "ON" "OFF")) (run-hooks (quote icicle-mode-hook) (if icicle-mode ... ...)) (if (called-interactively-p ...) (progn ... ...)))
;;   icy-mode()
;;   eval-buffer(#<buffer  *load*> nil "/home/jixiuf/.emacs" nil t)  ; Reading at buffer position 601
;;   load-with-code-conversion("/home/jixiuf/.emacs" "/home/jixiuf/.emacs" t t)
;;   load("~/.emacs" t t)
;;   #[nil " \205\264

Joseph

MichaelHeerdegen was kind enough to take a look. He wasn’t able to reproduce the problem, but he thinks it might be due to a recently fixed typo in the sources. Could you please download the Icicles sources and try again. Try first without byte-compiling (remove any byte-compiled files), to simplify.

Let me know if you still see a problem. Sorry for your trouble. You can reach me by email (‘M-x icicle-send-bug-report’) if you continue to have the problem. Thx – DrewAdams

Closed – communication by email. Downloading fixed the problem. – DrewAdams


Hello there, whenever I use icicles for displaying completions using [TAB], the cursor jumps back into the position before first hitting [TAB]. Example (key pressed - minibuffer input (with cursor being "|")):

M-x - Execute command: |
o   - Execute command: o|
r   - Execute command: or|
TAB - Execute command: or|     ;; buffer *Completions* shows up
g   - Execute command: org|
    - Execute command: or|g    ;; at this point I have *not* pressed any key. This change happens automagically after some hundred msec.
->  - Execute command: org|    ;; -> := Right Arrow Key
-   - Execute command: org-|   ;; this is the hyphen key
    - Execute command: or|g-   ;; again, the cursor position jumps back after some hundred msec without any input from me happening

I’ve done this by starting emacs with: emacs -Q and evaluating “(require ‘icicles)” and “(icy-mode)” from within my .emacs file. I use newest icicles (just re-installed them, not byte-compiled) and Emacs 24.0.50.1. Any thoughts on how to solve this? – ThomasK

Your report is pretty clear, Thomas; thanks. But I cannot reproduce it. I’m using Windows, and the latest Emacs 24 build I have is from 2011-01-31. I assume you started from emacs -Q – if not, do so, to eliminate any interaction with other stuff in your init file. What platform are you on, and what is your Emacs build date? Do you see any other cursor movement anomalies in the build, other than with Icicles?

I vaguely recall seeing some mail in emacs-devel@gnu.org about cursor jumping recently, but I did not read or save those messages. It might have been this (inconclusive) thread: http://lists.gnu.org/archive/html/emacs-devel/2011-02/msg00107.html. The description is not quite the same (it concerns Gnus, but perhaps the problem is related. It’s important to find out whether this happens only with a recent Emacs build etc.

Please use emacs -Q and see if you can find out whether this is related to some recent change (e.g. bug) in Emacs. If possible, test with Emacs 23.2 or an older Emacs 24 build, to compare. That will help a lot to narrow things down.

If you cannot find out anything, then we’ll have to try debugging. Better to do that by email. Using the debugger itself will likely interfere with the behavior, but you can try that and try adding ‘message’ statements to examine the state etc. Contact me directly in this case. Sorry for your trouble. – DrewAdams

Or perhaps it was this emacs-devel thread (which is very long and, again, inconclusive): http://lists.gnu.org/archive/html/emacs-devel/2011-01/msg00477.html. But that seems to be for Emacs 23.2.92 (a recent pretest for Emacs 23.3). – DrewAdams

I’ve just now pulled the newest emacs updates from the repo (my emacs was like, 1 week old) - and that fixed it. No idea what the problem was, but I’m glad now its fixed. Sorry about the trouble. – ThomasK

No problem. We all go through it. It’s part of the price to pay for using the dev version. Glad there’s no Icicles bug to fix for this. – DrewAdams


The function tmm-menubar fails with the following backtrace.

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  string-width(nil)
  tmm-get-keymap((S-iso-lefttab . icicle-complete-keys) nil)
  #[(elt) ...
  mapc(#[(elt) ...
  tmm-prompt((keymap (S-iso-lefttab . icicle-complete-keys) ...
  tmm-menubar()
  eval((tmm-menubar))
  eval-last-sexp-1(nil)
  eval-last-sexp(nil)
  call-interactively(eval-last-sexp nil nil)

I am running Emacs 24.0.50.1, and Icicles 22.0 (Update #: 22764). I used to use this command often (it’s bound to M-`), and I like Icicles very much (and use it even more), so it is quite annoying that Icicles breaks it. – Aidalgol 2010-07-21 22:46 UTC

1. I do not support development snapshots of Emacs. Too volatile and unstable. Icicles supports Emacs releases 20, 21, 22, and 23 – and it will support 24 when that is released.

2. I nevertheless took a look at this. Icicles broke nothing. It is Emacs that broke something. I have filed an Emacs bug: #6690. http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6690

3. Consider using LaCarte instead of ‘tmm’. It lets you take advantage of Icicles matching etc., among other things.

Just because you stumble upon a problem that you see only when using Icicles does not mean that Icicles broke something.

DrewAdams

Thanks. Looking at the backtrace, I thought that it was Icicles that broke something. I’ll take a look at LaCarte. – Aidalgol

Thanks; no problem. Moving this to IciclesIssuesClosed. – DrewAdams


When I try icicle-find-file and if I press ENTER without changing the default value which is current working directory, nothing happens. I expect the dired buffer of current working directory would appear. Tested with GNU Emacs 23.1.1 (i686-pc-linux-gnu, GTK+ Version 2.10.4) of built by me. Tested while running emacs -Q and only invoking icicles. – ThomasLim

Thanks for the report, Thomas. Should be fixed now – let me know.

It’s weird, but on 2008/12/27 I specifically changed from what I have now to what I just replaced for this fix. I don’t recall why. So it’s possible this fix will break something else ;-) – we’ll see. Thx – DrewAdams

It’s fixed. Thank you, Drew. – ThomasLim



Running the latest icicles as of 17 Feb, 2009 on Emacs 23.1.1 Icicles appends a ‘/’ when there is a single completion for a directory when running find-file.

Here is the file structure:

~/maindir/
          subdir/
                 file

And here is how to reproduce:

           
~/> emacs -q
require 'icicles [<RET>]
M-x icy-mode [<RET>]

[C-xC-f]
+ File or directory (/): ~/
[main<TAB>]
+ File or directory (/): ~/maindir/ [Sole prefix completion]
[<TAB>]
+ File or directory (/): ~/maindir// [Sole prefix completion]  <-- unexpected append of '/'
[<TAB>]
  *Completions* opens with a listing of all the files in /
 In emacs -q it works as expected
[C-xC-f]
Find file: ~/
[main<TAB>]
Find file: ~/maindir/
[<TAB>]
Find file: ~/maindir/subdir/
[<TAB>]
Find file: ~/maindir/subdir/file

It works as expected when the only completion is a regular file.

The following also works:

[C-xC-f]
+ File or directory (/): ~/
[main<TAB>]
+ File or directory (/): ~/maindir/ [Sole prefix completion]
[.<S-TAB>]
  *Completions* opens with the following content:

Click <mouse-2> or type RET on a completion to select it.  (C-?: help) 
Possible completions are:
../						   subdir/

The following also works:

[C-xC-f]
+ File or directory (/): ~/
[main<TAB>]
+ File or directory (/): ~/maindir/ [Sole prefix completion]
[s<TAB>]
+ File or directory (/): ~/maindir/subdir/ [Sole prefix completion]

I have tried this on 21.3.1 and it seems to work normally. – iulianov

Thanks for your report, Iulianov. Yes, I know about this bug. I just haven’t found the time yet to fix it. I’ll get to it eventually. Sorry for the trouble. Thx – DrewAdams

Sorry it took a while, but I think this is fixed now. Please try the latest version and let me know if you find any problems. Sorry for the trouble. Thx – DrewAdams


Hi Drew, I am using icicles with AUCTeX ans it works almost perfect with everything except TeX-complete-symbol in tex.el.

The main thing is that Icicles seems to generate ‘*Completion*’ buffer (with all the effects like hiding other buffers) but does not jump to minibuffer and stays in original one. So,it’s sort of default behavior of TeX-complete-symbol but with ICY ‘*Completion*’ buffer. Each time I call for completion, all the buffers are rearranged, with no back up afterwords.

I am an elisp dufus, sorry 😟. Can you please suggest how to modify TeX-complete-symbol to make it work with Icicle.

Thanks a ton! – RedBlue

1. Wrt AUCTeX, be aware of this AUCTeX bug. It doesn’t sound like it’s related to your problem, but be aware of it.

2. When you use ‘Tex-complete-symbol’ it uses nothing from Icicles that I can see, except its redefinition of ‘display-completion-list’. So that must be what you’re trying to describe.

It’s not clear to me what effect you are describing, however. What do you mean by all the buffers being rearranged and ‘*Completions*’ “hiding other buffers”? The only difference I would expect is wrt the display of completions within ‘*Completions*’ and possibly the window size. You can try sending me (or posting here) a screenshot.

You can also try adjusting these user options that affect ‘*Completions*’ display, to see if it helps. They are:

There are some other options that also affect ‘*Completions*’ display, but I doubt they are related. To see all such options and their docs, use ‘M-x customize-group RET Icicles-Completions-Display RET’. But I’m not sure any of the options that affect ‘*Completions*’ display are related to what you are trying to describe.

3. You also seem to be asking why Icicles completion is not available for this command – e.g. why the minibuffer is not used etc. Icicles is mainly about minibuffer completion, not in-buffer text completion such as symbol-completion. In a few instances, I have also added support for some buffer-text completion commands, but they are the exception, since they need to be defined case by case. IOW, buffer-text completion commands generally do not use ‘completing-read’, so they do not benefit automatically from Icicles.

Icicles does not do anything special for this particular command; it provides no Icicle-mode replacement for it. So what you get is just the vanilla command, but with the ‘*Completions*’ display differences mentioned, due to the redefinition of ‘display-completions-list’.

If you want Icicles-style completion for this command, you will need to define a replacement command for it. I don’t have the time now to do that (and I can’t be bothered to do it for each possible such symbol-completion vanilla command).

I have done that for ‘lisp-complete-symbol’, ‘bbdb-complete-name’, and ‘dabbrev-completion’. If you look at those, and compare the Icicles definitions to the originals, you will likely see how to adapt ‘TeX-complete-symbol’ to get Icicles completion. The idea is to change only the part of the code that handles the case where there are multiple completions. In that case, you want to let Icicles use the minibuffer, calling ‘completing-read’.

The most important thing for me here is #2. Please let me know more clearly what the display problem is: what you see that you do not want to see. Mail me a screenshot if you like. I’ll take a look and at least get back to you with an explanation, if not some better help. Thx – DrewAdams


Yes, thanks a lot for detailed (as always) explanations. I will do as you said at #3 and try to learn some lisp at the same time.

Concerning #2, I am already embarrassed to have bothered you with that. It was some glitch or something that I can not reproduce after restart of the emacs sessions. If I encounter it once again I will definitely make a screen-shot and send it to you. – RedBlue

No problem. If you do try #3 and succeed, I can probably include what you come up with in Icicles, if you like. If you have trouble trying #3 and have questions, email me; perhaps I can help. – DrewAdams

So here I am with an screen-shot. The main problem is resizing of the bottom buffer. Indeed the resizing does not happen if I have 3 or more windows. But the problem occurs with 2 windows. Here is the image with buffers before the completion: beforeTeX-Completion

and after: afterTeX-Completion

The only inconvenience is resizing the buffer back to normal hight. – RedBlue

What’s not clear to me is what is different here from when you do not use Icicles. I would expect the completions shown in the buffer to be displayed a bit differently (e.g. spacing), and perhaps the window height to be a bit different (see the options mentioned above), but what differences do you see that bother you? I believe that in both cases the ‘*Completions*’ window is not removed (but with Icicles you can remove it by doing `C-]’). – DrewAdams

Without icicles the window is not resized. With icicle instead the new window size is much smaller and I need to resize it to normal height (which i don’t know how to do except by using the mouse; very inconvenient). With `C-]’ it removes the buffer but did not restore the window height. – RedBlue

OK, I understand. FYI:

  • `C-x ^’ enlarges or shrinks the window, `C-x +’ makes the window heights the same. See Change Window.
  • Command ‘icicle-remove-Completions-window’ removes the ‘*Completions*’ window. You can bind this to a key globally, if you want. It is already bound in the minibuffer to ‘C-x 0’, so, for example, ‘M-x C-x 0’ removes it.
  • In an active minibuffer, `C-]’ (‘icicle-abort-recursive-edit’) removes the ‘*Completions*’ window. So `M-x C-]’ removes it (the ‘M-x’ just makes the minibuffer active).

There is no good way to return the window to its size before completion in all cases, since there is no way, especially in the case you describe, to know that completion is finished (i.e. know that the user is finished with the buffer/window).

I could think about providing some way to deal with this, but remember that you will normally want the ‘*Completions*’ window to take up less space when there are few completions. FYI, the relevant code is ‘icicle-fit-completions-window’. This is not my first priority, however, and it’s not sure that a reasonable trade-off is possible. Possibly, I could add an option that prevents resizing or specifies a minimum height (analogous to ‘icicle-Completions-window-max-height’) or something similar. – DrewAdams

Thanks Drew. `C-x +’ does the job indeed. That’s exactly what I needed. Following the link I discovered the winner-mode which can undo all the changes to the windows - a real blessing, as far as I am concerned.

I will take your advice at #3 above and will try to alter the ‘TeX-complete-symbol’ when I have some spare time.

Great; good to hear. Sorry for your trouble. Let me know if you come up with a definition of ‘TeX-complete-symbol’ for Icicles. – DrewAdams


When I use your icicles in emacs22, I get a message “Symbol’s function definition is void: icicle-shell-command”. – ahei

Sorry, that doesn’t help me enough. I don’t see that problem in Emacs 22.1, 22.2, or 22.3. Perhaps something from your init file is interfering.

Please (always) provide a recipe to reproduce the problem, starting with emacs -Q. It’s probably easiest to correspond by email – use ‘M-x icicle-send-bug-report’. – DrewAdams

Oh, I’m sorry for that. I found the reason, kde-emacs is conflict icicles, I must load icicles before kde-emacs in emac22, otherwise will get that error message. and, MultiTerm is also conflict with icicles in emacs 22 and 23, must load icicles before multiterm, otherwise, when exit ediff, will get message “Lisp nesting exceeds ‘max-lisp-eval-depth’”. – ahei

Could you maybe investigate a bit what the problem was? In general, Icicles does its best to not depend on the order of loading or on when Icicle mode is activated. But that can be tricky. It would be good to understand just what the problem was – either to improve Icicles or to provide info to the maintainers of the other libraries, so they can fix things if appropriate.

One thing you might try would be to use the load order that doesn’t work correctly and then try to toggle ‘icy-mode’ twice, to see if that fixes the problem. That might give us some info about it.

If you don’t have the time to investigate, that’s OK, but if you could, it would be helpful, either to Icicles or possibly to the other libraries. Anyway, I’m glad you found a workaround, and thanks for trying Icicles. – DrewAdams

For those two problems I mentioned above, I all only load icicles (require ‘icicles), not activate icicle mode. and for MultiTerm, you can reproduce the problem by using following instructions:

emacs -Q
(require 'multi-term)
(require 'icicles)

then you use ediff, you will get message “Lisp nesting exceeds ‘max-lisp-eval-depth’”. multi-term advised command other-windows. and for kde-emacs, I’ll investigte it, but I’m not familiar with elisp, 😊 – ahei

OK, thanks. (Moved this to IciclesIssuesClosed.) – DrewAdams

Actually, I don’t see that error when I follow your instructions for MultiTerm. I did just what you said, but perhaps there is a missing step. I do see it, however, when I do ‘C-x 0’. The conflict is in fact with frame-cmds.el, not with Icicles. (Icicles soft-requires frame-cmds.el, so it uses it if it is in your ‘load-path’.)

As you suggested, the problem is that (1) multi-term.el advises ‘other-window’, and (2) frame-cmds.el redefines ‘other-window’. Multi-term’s advice finishes by calling an unadvised ‘other-window’, and frame-cmds’s redefinition finishes by calling the ‘other-window’ definition that was in effect before it was loaded.

If multi-term is loaded first, then its definition finishes by calling unadvised ‘other-window’, which is the frame-cmds redefinition, which finishes by calling the “original” definition, which was the advice… If frame-cmds is loaded first, then the original ‘other-window’ that it calls at the end is the original, unadvised ‘other-window’, and multi-term’s advice applies to the frame-cmds definition.

Function redefinition, which I tend to use more than advice, doesn’t always play well with redefinition of the same function by another library, and it doesn’t play well with advice. But advice has other problems (see AdviceVsHooks), so I often avoid it. I would probably use it more if it didn’t complicate using the debugger.

FWIW, the use of redefinition by Icicles itself should have no effect when Icicle mode is turned off – Icicles is very clean in this respect. The same is not true of the redefinition in frame-cmds, since there is no mode controlling its use.

Anyway, I won’t worry about this problem. But thanks for reporting it (and finding the workaround). – DrewAdams

oh, great, you are right, I put frame-cmds.el in my load-path, after I remove it from load-path, ediff is work well when I load multi-term before load icicles. – ahei

I have already investigated kde-emacs, but I’m not familiar with elisp and kde-emacs is a big package, and so not results for that,a bit pity.– ahei

I don’t understand your reply. Please try to rephrase it. What does it have to do with Icicles? Please keep messages here related to this specific bug. Report a new bug if you want to change the subject. – DrewAdams

I found the reason, kde-emacs is conflict icicles, I must load icicles before kde-emacs in emac22, otherwise will get that error message. – ahei

Could you maybe investigate a bit what the problem was? – DrewAdams

I have already investigated kde-emacs, but I’m not familiar with elisp and kde-emacs is a big package, and so not results for that,a bit pity.– ahei

I see. Sorry, I forgot that you had a problem with kde also; I was thinking about Multi Term. I don’t have or use kde-emacs, so I think we’ll just have to leave it there. At least you have the workaround that it works OK if you load Icicles first. – DrewAdams


emacs -Q
(require 'icicles)
M-x icicle-color-theme color-theme-aalto-dark RET, now color theme is color-theme-aalto-dark
M-x icicle-color-theme RET, I get error tip: "Symbol's function definition is void: ", and now  it cancel color-theme-aalto-dark 
and restore old color theme (RET does not exit the minibuffer successful.

ahei

1. I cannot reproduce that. What is the symbol that it complains about? You quoted only part of the error message. Are you sure you have all the latest Icicles files? What is your Emacs version? What version of ColorTheme are you using? Etc.

2. It is normal that the saved theme was restored when an error is raised. The snapshot was taken only once per Emacs session. That’s why the theme that was restored was your initial theme.

3. In any case, I’ve just uploaded a new version of icicles-cmd1.el that makes the change I suggested I would make. By default, a snapshot is now taken at the start of each invocation of the command. If you use a prefix arg, then no snapshot is taken (unless none has been taken for the current Emacs session). IOW, a prefix arg gives you pretty much the behavior of the previous version, and no prefix arg means that ‘C-g’ restores the state as it was before the command was invoked. – DrewAdams

I use your latest icicles-install, and have use it update latest icicles.

icicle-color-theme docstring said:

If you use `C-g' during this command, the previous color-theme
snapshot is used to restore that color theme.

By default, each time you invoke this command, a snapshot is first
made of the current color theme (or current colors, if no theme is
used).  Thus, by default, if you use `C-g', the colors restored are
those used before you changed themes using this command.

However, if you use a prefix arg, then this command takes no new
snapshot, unless no snapshot has ever been taken during this Emacs
session.  This can be useful when experimenting, to restore not to the
state just before this command invocation, but to some previous
snapshot.
emacs -Q
(require 'icicles)
(require 'color-theme)
M-x icy-mode

1.
M-x icicle-color-theme RET , I get error tip: "Symbol's function definition is void: ", this is 
whole message emacs give to me. and now color theme is also color-theme-aalto-dark, this is same 
as docstring said.

2.
M-x icicle-color-theme color-theme-aalto-dark RET, now color theme is color-theme-aalto-dark

M-x icicle-color-theme TAB C-up C-up C-up, now color theme is other, C-g C-g, and now color theme 
restore to color-theme-aalto-dark, this is same as docstring said.

C-u M-x icicle-color-theme TAB C-up C-up C-up, now color theme is other, C-g C-g, and now color theme 
restore to color-theme-aalto-dark, but this is not same as docstring said.

IOW, M-x icicle-color-theme and C-u M-x icicle-color-theme is same.

my system is ubuntu 8.04, and M-x emacs-version: GNU Emacs 23.1.2 (i686-pc-linux-gnu, GTK+ Version 2.12.9) 
of 2009-08-21 on ahei-ubuntu
I use color theme 6.6.0

ahei

Thanks for providing more info.

0. No need to require `color-theme.el’. If it is in your ‘load-path’, and the subdirectory ‘themes’ is in your ‘load-path’, then `color-theme.el’ and `color-theme-library.el’ will be loaded when you load Icicles. Check the value of option ‘icicle-color-themes’ after loading Icicles and before doing anything else. If it is empty, then the color-theme library wasn’t loaded at Icicles load time.

But please download the latest icicles-opt.el. I just fixed a bug in ‘icicle-color-themes’ initialization.

1. I don’t understand #1.

1a. You are getting the error after ‘RET’ just to enter the command name, before trying completion, correct? Perhaps the error is related to the bug I just fixed, but I doubt it. Normally, that error message shows the symbol whose function cell it claims is void. I’m surprised that you don’t see any symbol name.

1b. You say that after the error was raised the color theme was changed to ‘color-theme-aalto-dark’. An error causes the theme to be restored to the snapshot. The snapshot is created when the command is invoked. In your case, the command was barely invoked (you got an error before using completion), so it could be that the snapshot was not yet created.

But if the theme changed to ‘color-theme-aalto-dark’ then that must be the value of the snapshot, which means either that this was not the first time you invoked the command (your recipe was not accurate) or that was the theme that you started out with. Some info seems to be missing here.

Anyway, you will need to use the debugger to get some more info about what’s happening. After loading the Icicles source files (not byte-compiled files), do ‘M-x debug-on-entry icicle-color-theme’. Then do ‘M-x icicle-color-theme RET’ to try to reproduce the problem. Step through the debugger with ‘d’ (you can use ‘c’ for any sexp whose eval you want to skip through quickly). See what happens at the moment the first error is raised. To easily follow the execution, put the source file in another frame so you can see what’s happening. Let me know whatever you find out.

It’s easier to communicate about this by mail (backtrace contents etc.), BTW. ‘M-x icicle-send-bug-report’.

2. #2 shows that it works, in spite of the error raised in #1. I still need to understand what happened in #1, however.

You seem surprised by the last part of #2, but that is just what the doc string says. You exited normally the first time, giving you the dark theme. The second invocation created the snapshot to the dark theme (and ‘C-g’ restored it). The third invocation, with ‘C-u’, did not create a new snapshot, and your ‘C-g’ restored to the existing snapshot, which was, again, the dark theme.

‘C-u’ prevents taking a new snapshot at the time of command invocation. It leaves the existing snapshot as it was. Its purpose is just that: to not overwrite the snapshot, because you don’t want to save the current theme. But in your case, the current theme was the same as the snapshot (dark), so ‘C-u’ made no difference. It simply prevented overwriting the dark snapshot with a new dark snapshot (same thing).

You would have seen the utility of ‘C-u’ if you had not used ‘C-g’ but had exited with, say, a light theme, so the current theme would then have been different from the snapshot you had made earlier. Then, if you invoked the command again with ‘C-u’ and hit ‘C-g’, the dark theme would be restored, not the light theme that was in effect when the command was invoked.

IOW, if you always use ‘C-u’, then you don’t take snapshots. If you want to be able to restore to the current state, not to an earlier state, then do not use ‘C-u’. If you like some state, and you want to experiment with others and then come back to the state you liked, then use ‘C-u’ for all such experimentation – no new snapshots will be taken, and ‘C-g’ (or choosing pseudo-theme [Reset] using ‘color-theme-select’) will restore the state you liked.

The common case, I expect, is to want to restore things to the way they were when the command was invoked, that is, to cancel the effect of the current command (only). This was the point you raised before, complaining that the (older) behavior was not similar to, say, ‘icicle-frame-bg’. Now it is similar (if you don’t use ‘C-g’).

Please try to debug #1 a little and let me know what you find out. Thx – DrewAdams

1. sorry for my mistake and it taike doubt to you.

emacs -Q
(require 'icicles)
M-x icy-mode
M-x icicle-color-theme RET RET , I get error tip: "Symbol's function definition is void: ", this is 
whole message emacs give to me. 

2. I eventually understand your meaning, and it is complex, 😊

3. can icicle-download-wizard only download files which updated but not download all files in icicles?

ahei

1. Should be fixed now – raises an error for empty input; thanks. Download icicles-cmd1.el.

3. Not as far as I know. I didn’t write and don’t maintain the scripts etc. for downloading Icicles files. Feel free to send a patch to improve it. However, “only download files which updated” means what? Updated since when? Since Ahei’s last use of the wizard? ;-) – DrewAdams

1. It work now.

3. Icicles can record a version number, then update tool just detect version number which many windows’s softwares do. 😊 – ahei

1. Good to hear.

3. Sorry, not interested. I update individual files as needed. Each file has an individual Update # in the header. I do not want to version Icicles as a whole.

I was only half-kidding about “since Ahei’s last use of the wizard”. It should be possible for the wizard to record the date of the last download and compare that with the dates on the wiki. Just a suggestion.

But if someone doesn’t download Icicles often, there is no problem in simply downloading all of the files. And if someone does update his copy of Icicles often, then it’s no big deal to compare the file dates and download only the files that are more recent than what s?he has locally. – DrewAdams


Your iciclies is conflict with ido, I remove

 (find-file icicle-file t) ; `C-x C-f'

from icicle-top-level-key-bindings, but the keys I bind to ido still do not work, how can I fix this problem? – ahei

1. Removing that binding means that ‘C-x C-f’ will retain whatever top-level binding it would have normally, without Icicles. In ‘emacs -Q’, that binding is command ‘find-file’. If you or some library that you use binds ‘C-x C-f’ to some other command, then that binding will still be in effect in Icicle mode. Icicles makes no top-level bindings, other than those defined by option ‘icicle-top-level-key-bindings’.

2. This is about the top-level binding of ‘C-x C-f’. It has nothing to do with any minibuffer key bindings. (Icicles does not bind ‘C-x C-f’ in the minibuffer, in any case.)

3. Yes, Icicles is in conflict with Ido, or, rather, Ido is in conflict with Icicles ;-). The Icicles minibuffer behavior and bindings are close to those of vanilla Emacs. Ido uses the minibuffer in incompatible, modal ways.

If you just want the buffer-switching behavior of Ido, then you can use IswitchB with Icicles. You cannot use Ido with Icicles.

See the links listed here: Ido and Icicles, as well as some of the ensuing discussion, for more information. – DrewAdams

Thanks for your reply. I think ido is better for using find file or switch buffer, so, I want use you Icicles, I also want use ido, I remove following statement from icicle-top-level-key-bindings

    (switch-to-buffer               icicle-buffer                   t) ; `C-x b'
 (find-file icicle-file t) ; `C-x C-f'

and my icicle-top-level-key-bindings is configure to:

(setq icicle-top-level-key-bindings
        `((,(kbd "<pause>") icicle-switch-to/from-minibuffer    t) ; `pause'
          (,(kbd "C-c `")   icicle-search-generic               t) ; `C-c `'
          (,(kbd "C-c $")   icicle-search-word                  t) ; `C-c $'
          (,(kbd "C-c ^")   icicle-search-keywords              t) ; `C-c ^'
          (,(kbd "C-c '")   icicle-occur                        t) ; `C-c ''
          (,(kbd "C-c =")   icicle-imenu                        t) ; `C-c ='
          (,(kbd "C-c \"")  icicle-search-text-property         t) ; `C-c "'
          (,(kbd "C-x M-e") icicle-execute-named-keyboard-macro t) ; `C-x M-e'
          (,(kbd "C-x SPC") icicle-command-abbrev               t) ; `C-x SPC'
          (,(kbd "C-x 5 o") icicle-select-frame                 t) ; `C-x 5 o'
          ,@(and (require 'kmacro nil t) ; (Emacs 22+)
                 `((,(kbd "S-<f4>")    icicle-kmacro            t))) ; `S-f4'
          (abort-recursive-edit           icicle-abort-recursive-edit     t) ; `C-]'
          (minibuffer-keyboard-quit      icicle-abort-recursive-edit ; `C-g' (minibuffer - `delsel.el')
                                         (fboundp 'minibuffer-keyboard-quit))
          (execute-extended-command       icicle-execute-extended-command t) ; `M-x'
          ;; There are no key bindings in vanilla Emacs for `insert-buffer'.
          ;; If you use `setup-keys.el', then these are its bindings: `C-S-insert', `M-S-f1'.
          (insert-buffer                  icicle-insert-buffer            t)
          (bookmark-set                   icicle-bookmark-cmd             t) ; `C-x r m'
          (bookmark-jump                  icicle-bookmark                 t) ; `C-x r b'
          (bookmark-jump-other-window     icicle-bookmark-other-window    t)
          ;; Don't let Emacs 20 or 21 use `substitute-key-definition' on `M-.' or `M-*', since we need
          ;; these keys for the minibuffer.  Leave them unbound in `icicle-mode-map' until Emacs 22+.
          (pop-tag-mark        icicle-pop-tag-mark          (fboundp 'command-remapping)) ; `M-*'
          (find-tag            icicle-find-tag              (fboundp 'command-remapping)) ; `M-.'
          (eval-expression     icicle-pp-eval-expression    (fboundp 'command-remapping)) ; `M-:'
          (pp-eval-expression icicle-pp-eval-expression (fboundp 'command-remapping)) ;`M-:' (`pp+.el')
          (find-tag-other-window        icicle-find-first-tag-other-window t) ; `C-x 4 .'
          (kill-buffer                  icicle-kill-buffer                 t) ; `C-x k'
          (kill-buffer-and-its-windows  icicle-kill-buffer                t) ; `C-x k' (`misc-cmds.el')
          (delete-window                icicle-delete-window               t) ; `C-x 0'
          (delete-windows-for           icicle-delete-window             t) ; `C-x 0' (`frame-cmds.el')
          (other-window-or-frame        icicle-other-window-or-frame     t) ; `C-x o' (`frame-cmds.el')
          (other-window                 icicle-other-window-or-frame       t) ; `C-x o'
          (exchange-point-and-mark      icicle-exchange-point-and-mark     t) ; `C-x C-x'
          (where-is                     icicle-where-is                    t) ; `C-h w'
          (,icicle-yank-function        icicle-yank-maybe-completing       t) ; `C-y'
          (set-mark-command
           icicle-goto-marker-or-set-mark-command                          t) ; `C-@', `C-SPC'
          (pop-global-mark
           icicle-goto-global-marker-or-pop-global-mark                    t) ; `C-x C-@', `C-x C-SPC'
          ;; For La Carte (`lacarte.el'), not Icicles, but it's convenient to do this here.
          (,(kbd "ESC M-x")      lacarte-execute-menu-command
           (fboundp 'lacarte-execute-menu-command)) ; `ESC M-x'
          (,(kbd "M-`")          lacarte-execute-menu-command
           (fboundp 'lacarte-execute-menu-command)) ; `M-`' - replaces `tmm-menubar'.
          (,(kbd "<f10>")        lacarte-execute-menu-command
           (fboundp 'lacarte-execute-menu-command))) ; `f10' - replaces `menu-bar-open'.
        )

now, C-x b call ‘ido-switch-buffer’, and C-x C-f call ‘ido-find-file’, but when “C-x b”’s behavior is normally as without Icicles’s top-level key binds, “C-x C-f”’s (now it really bind ido-find-file) behavior is not normally as without Icicles’s top-level key binds, it’s behavior is same as when find-file is bind to icicle-file, I call M-x ido-find-file, it’s behavior is same as when find-file is bind to icicle-file, and my settings for ido is do not work, my settings for ido is:

(if is-before-emacs-21
    (progn
      (load "ido-for-21")
      (setq read-buffer-function 'ido-read-buffer))
  (require 'ido)
  (ido-everywhere t)
  (setq ido-define-mode-map-hook 'ido-setup-hook))

(add-hook ido-define-mode-map-hook 'ido-my-keys)

(ido-mode t)
(global-set-key (kbd "C-x C-f") 'ido-find-file)

(defun ido-my-keys ()
  (unless is-before-emacs-21
    (setq ido-mode-map ido-completion-map))
  (define-key ido-mode-map "\C-u" 'ido-prev-match)
  (define-key ido-mode-map "\M-." 'ido-next-match-dir)
  (define-key ido-mode-map "\M-," 'ido-prev-match-dir)
  (define-key ido-mode-map "\C-h" 'ido-delete-backward-updir)
  (define-key ido-mode-map "\C-w" 'ido-delete-backward-word-updir)
  (define-key ido-mode-map (kbd "C-n") 'ido-next-macth))

and my face settings for ido is also do not work,

;; ido face
(if is-before-emacs-21
    (progn
      (if window-system
          (custom-set-faces '(ido-first-match-face ((((class color)) (:bold nil :foreground "yellow")))))
        (custom-set-faces '(ido-first-match-face ((((class color)) (:foreground "yellow"))))))
      (custom-set-faces '(ido-only-match ((((class color)) (:bold nil :foreground "green"))))))
  (require 'ido)
  (if window-system
      (custom-set-faces '(ido-first-match ((((class color)) (:bold nil :foreground "yellow")))))
    (custom-set-faces '(ido-first-match ((((class color)) (:foreground "yellow"))))))
  (custom-set-faces '(ido-only-match ((((class color)) (:bold nil :foreground "green"))))))

I do not know the reason. and, when icy-mode is active, ido-find-file’s behavior is: I type C-x C-f, then type Backspace key, I get message in minibuffer, “Text is read-only”. I run emacs with “-q”, then active settings for ido and icicles, but behavior is same as above.

As I tried to say, Ido will not work with Icicle mode active, and Icicles will not work with Ido active. Each tries to use the minibuffer in its own way. Icicles uses the minibuffer the way vanilla Emacs does, for the most part. Ido does not.

The problem is not the top-level binding for ‘C-x C-f’ or ‘C-x b’. The problem is conflicts within the minibuffer (key bindings, faces, etc.).

I’m sorry, but you will have to choose between the two. If you want everything to be Ido-like, then you will have to choose Ido and forego Icicles. If you just want some of Ido’s behavior, then you can follow the links I pointed you to, to find out how to configure Icicles to give you similar behavior in various respects. And you can use IswitchB with Icicles to give you Ido’s buffer-switching behavior.

That’s the only help I can give you, I’m afraid. Again, to be clear, the problem is not any top-level bindings. You can get rid of all top-level Icicles bindings, and it will not help. The problem is minibuffer bindings, and minibuffer behavior in general. Ido just does not play well with the standard minibuffer. – DrewAdams

OK, I see, thank you!


Dear Drew,

I noticed a weird behavior of my Icy completion in e-lisp mode. When I invoke (lisp-complete-symbol), the prompt jumps to minibuffer and nothing happens. So I need to press additional TAB even if there is a sole completion.

In short, can I have the default completion behavior:

  • first invocation of lisp-complete-symbol (‘M-TAB’) completes the symbol in place to a common root.
  • second invocation jumps to minibufer and completions are automatically shown ( if I pressed ‘M-tab’ twice I already want to see all available candidates and additional ‘TAB’ is somewhat time consuming and disturbing).

Thanks. – SpinuVit

I’m not sure what you mean. If I hit ‘M-TAB’ with the cursor after the text ‘forward-para’, then I see this in the minibuffer:

 Complete Lisp symbol: forward-para

If I then hit ‘TAB’ (or ‘RET’) once, the text in the buffer is completed to ‘forward-paragraph’, since that is the sole completion. IOW, what you describe as wanting is pretty much what I see in this regard.

However, completion takes place in the minibuffer, so, as you say, completing to a common prefix among several completions is not done in the buffer – you see it in the minibuffer instead.

I don’t see a bug here, unless I’m missing something. But the Icicles behavior is different from the vanilla behavior. If you prefer the vanilla behavior, these are your options:

  • quit Icicle mode, at least temporarily
  • customize ‘icicle-redefine-standard-commands-flag’ to ‘nil’

In the latter case, however, you will lose Icicles completion also for other things – see the definition of function ‘icicle-redefine-standard-commands’ for the list.

HTH – DrewAdams

My post was deleted 😟 Accidentally probably.

There is clear inconsistency between `icicle-comint-dynamic-complete` and `icicle-lisp-complete-symbol`. The latest jumps directly to minibufer even if there is a sole completion or common root. Say I have icy-mod in my buffer, then ‘icicle-lisp-complete-symbol’ will just jump to minibuf for one single letter!!

My second part of the question was about popping \*completion\* buffer immediately after entering the minibuf (i.e. after second M-Tab). That for obviuous reasons - once one pressed M-TAB twice he defenitelly wants to see available completions.

I really hope the point above could be sorted out. Iciles offers an unique feature for completion and it would be a pity if these minor inconsistencies spoiled the story.

Many thanks. – SpinuVit

1. No, your post was simply moved here, as the log said – check RecentChanges to see changes.

2. Yes, ‘icicle-comint-dynamic-complete’ and ‘icicle-lisp-complete-symbol’ act differently.

3. Yes, if you hit ‘M-TAB’ after ‘icy-mod’, completion is done in the minibuffer. Just hist ‘TAB’ or ‘RET’ to complete to ‘icy-mode’.

4. There is no pressing of ‘M-TAB’ twice. That simply doesn’t exist. In vanilla Emacs, repeating ‘M-TAB’ scrolls ‘*Completions*’. In Icicles it does not – use ‘C-v’ or ‘M-v’ to scroll ‘*Completions*’.

5. If you are asking why ‘M-TAB’ doesn’t show ‘*Completions*’ initially, the answer is that that was the design choice. If you want to always show ‘*Completions*’ initially, customize option ‘icicle-show-Completions-initially-flag’. You might also consider using icomplete+.el, to see the possible prefix completions in the minibuffer.

6. As I said, you can return to the vanilla Lisp-symbol completion, if you prefer that, by simply customizing ‘icicle-redefine-standard-commands-flag’ to ‘nil’.

HTH – DrewAdams

(#4) In vanilla Emacs, first M-Tab completes the symbol in place, second (if any) opens the ‘*Completion*’ buffer.

In Icy-mode first M-Tab jumps to minibufer (without completing to common match). Next, ‘TAB’ or ‘RET’ will complete to common match, next RET (TAB) will place the candidate in original buffer,( will open the ‘*Completions*’ and only next `TAB` will start cycling).

So Icicles adds 2-3 additional key strokes even in a trivial case when there is obvious one completion candidate.

wouldn’t it be nicer if when there is only one completion candidate or common root just to insert it in place (as vanilla Emacs does), then next ‘M-TAB’ will jump to minibuf and activate ‘*Completions*’? Looks like a reasonable and very efficient behavior to me.

(#5) Thanks for the tip of icomplete+.el. Setting ‘icicle-show-Completions-initially-flag’ does not work for me. I remember it worked some time back, and it was rather annoying for M-x, buffer and file completion, so no way can usefully use it. For in-buffer completion, instead, it would be really useful to have a separate configuration flag. Don’t you think?

For in-buffer completion the number of candidates is usually small, and as I already said when you press second M-Tab you probably don’t know that to type next and expect to see all available completions.

(#6) This is not an option. I like icicle ‘*completion*’ and not willing to abandon it because of a couple of additional keys (however annoying they can be). – SpinuVit

(#4) Yes, it would be nicer, but it is not feasible, given the current design. When there are multiple candidates, I just call ‘completing-read’. There is no way to tell ‘completing-read’ to also complete: it just opens the minibuffer to read with completion. Yes, it could be done, using ‘try-completion’, as I did for ‘icicle-dabbrev-completion’, but I probably won’t do it, at least not anytime soon. This is just not my priority, sorry. But I will add it to my maybe-to-do list. As you say, there are typically few candidates, so the use of Icicles completion here is not that big an advantage – vanilla ‘M-TAB’ is a reasonable alternative, which you might prefer.

(#5) No, I don’t think so. See #4.

(#6) You don’t need to abandon Icicles completion in general, just because you forego it for in-buffer symbol completion. In addition, you might find ‘C-M-/’ (‘icicle-dabbrev-completion’) useful in this context. It generally behaves more like what you want, I think. Its domain of candidates is not the same as ‘M-TAB’, but it often DTRT. – DrewAdams

I implemented it. I think it does what you requested now. Please take a look. Thx – DrewAdams


[What’s written at Icicles - Customizing Key Bindings#MinibufferBindings] does not work for (define-key map [(meta space)] 'icicle-narrow-candidates). Meta-space is hard-coded somewhere. How can one change it? – SpinuVit

‘M-SPC’ is not hard-coded; it is soft-coded. Customize ‘icicle-word-completion-keys’ to something other than ‘M-SPC’. – DrewAdams

works fine, thanks. – SpinuVit


Also modifying ‘C-h a’ to `icicle-apropos` in ‘icicle-top-level-key-bindings’ does not work 😟. Any ideas. Thanks. – SpinuVit

It works for me. But you need to remap the command that ‘C-h a’ is bound to by default, ‘apropos-command’. In Customize , you click ‘INS’ to add an entry, then choose ‘Command to remap’ in the ‘Value Menu’, then enter icicle-apropos as the command to remap (under ‘Choice’), enter icicle-apropos as the ‘Command’, and enter t as the value of ‘Condition’. Then set or save. It works for me. – DrewAdams

Yap, works!! I tried with nil initially, that was the wrong cook. Thanks. – SpinuVit


Hi, i’m trying to use icicle-search-buffer to perform a search and replace on all open buffers. But i just cannot get it to work. Here’s what i’m doing (windows, emacsw32 v23.0.x, icicles from current CVS):

1. M-x icicle-search-buffer RET
2. Find (regexp): \(\.\.\\\)*xxx\\yyy RET
3. Subgroup to use as search context [0, 1, 2,...] (default 0): 0 RET
4. Choose buffer (`RET' when done): .* S-Tab <completion window with all buffers selected> M-!
5. Choose buffer (`RET' when done): RET
6. Choose an occurrence: C-S-RET
7. Replace with: $(Dir)\xxx\yyy RET
8. 'No match for $(Dir)\xxx\yyy' appears in echo area for a short time) and i'm back at 6.

Now, i was trying for quite some time to convince icicles to perform my replacement until i finally realized, that what doesn’t work are the single ‘\’ in the replacement string (this is emacs 23.0.x on windows). As soon as i replaced them with ‘
’ i actually got a hit. So i finally could continue with:

9. Choose an occurrence: M-,
10. Replace with: $(Dir)\\xxx\\yyy RET
11. Choose an occurrence: C-S-RET
12. Choose an occurrence: C-|

But it took me more than an hour (ok, feels stupid now) to realize what’s happening. So maybe it would be possible to provide some more meaningful error message than just the ‘No match for …’?

Also, what is really expected as input in 6. wasn’t quite clear to me. I’ve been trying a lot of different things here (like using ‘.* S-Tab M-!’ to select all occurrences, and a couple of other stupid things). It might be worth adding some example to the documentation?

Ok, then i realized that my replacement did not work and that the search had to be changed to:

2a. Find (regexp): \(\(?:\.\.\\?\)*\)\(\\xxx\\yyy\) RET

with a replacement of:

10a. Replace with: ..\\..\\..\\\1\\aaa\\bbb\\ccc\2 RET

But now, \1 and \2 are somehow not getting replaced with the matches from the search expression.

E.g. an input of:

..\xxx\yyy\zzz

would result in:

..\..\..\\aaa\bbb\ccc\zzz

However, a normal query-replace-regexp with the same search/replacement expressions and input is giving the expected result of:

..\..\..\..\aaa\bbb\ccc\xxx\yyy\zzz

I’m lost - no clue what i’m doing wrong now.

Thanks for any pointers in the right direction! – Kai

Hi, Kai. Sorry for your trouble.

I have difficulty following your example – there is too much going on at once here, for one thing. A couple of suggestions:

1. Let’s do this by email, since it sounds like there will be a bit of discussion, to be able to understand the situation etc. Send me a mail via ‘M-x icicle-send-bug-report’. Don’t repeat what you’ve already said. The place to start is with something simpler.

2. We need to break it down into the separate questions. First, I need to know what does work. Give me an example of what you’re doing, but using a very simple regexp – no backslashes etc. That will make sure we’re on the same page wrt the expected sequence of events and whether things basically work or not. Once we’ve got that down, we can proceed to fancy regexps, fancy replacements, etc.

Give me a recipe with just a few, simple buffer names – maybe just one – and a simple regexp (e.g. a literal string) and a simple replacement string – no `\,’ constructs etc. Then we’ll make it more complex bit by bit.

4. You say that you used `M-!’. That won’t work for Icicles search and replace. `M-!’ applies an action that is designed to act on a list of candidates. What you want is `C-|’, which is an alternative action (which is replacement, for Icicles search) and which acts on each candidate – not on the list of candidates. Summary:

  • `C-!’ – normal action, applied to each candidate
  • `M-!’ – normal list action, applied to the list of all candidates
  • `C-|’ – alternative action, applied to each candidate – for search, this is replacement
  • `M-|’ – alternative list action, applied to the list of all candidates

For Icicles search, no list actions are defined – no `M-!’, no `M-|’. For search, the normal action browses search hits, so applying the normal action to each hit in turn makes no sense – so no `C-!’ either (it’s not undefined, but it’s useless). If you want to perform replacement for all candidates, then you want to apply the alternative action to each candidate: `C-|’.

I know there is a lot to get used to. But once you do, it’s pretty logical.

We’ll eventually get to your fancy replacement, but let’s do it a step at a time, making sure both (a) that we’re on the same page and (b) that things do in fact work as they should. ;-)

Once we understand each other and we are sure things work as they should, we can discuss how I might make things clearer in the doc. Thanks for your patience. Hopefully, it will be rewarded.

Thx – DrewAdams

Followed up with Kai off-wiki. There was indeed a bad bug, which I’ve hopefully fixed now. Thx – DrewAdams


Shift-tab completion is extremely slow for me. I’ve byte compiled all the Icicles .el files, but it still takes about 10 seconds just to do a completion for my currently open buffers (about 10 of them). Any idea why this would be the case? Thanks. – Divia

Please try the latest version. I introduced a bug recently, which caused a 10-sec delay whenever the input was completed completely. If the latest version doesn’t fix the problem you see, then please provide a precise recipe to reproduce it, starting from emacs -Q. Thx – DrewAdams

Thanks for the reply. I installed bzr and used bzr branch http://archives.hodique.info/bzr/icicles/ to get the latest version of icicles, but now Shift-Tab completion isn’t working at all. When I try to do it when switching buffers, I get this error: “Wrong type argument: sequencep, switch-frame\ \ =\ \ handle-switch-frame”. I’m using Aquamacs Emacs 1.7, and to get this error I just type C-x b editor Shift-Tab. Let me know if you need any more information. Thanks, – Divia

I think you picked up a very old version of Icicles. As it says at Bulk Icicles Download, the bzr repository has not been updated for a long time. Please bulk download from EmacsWiki, either from within Emacs (icicles-install.el or auto-install.el) or using shell script get-icicles.sh, or download the files individually at ElispArea. Let me know if you still have a problem with the latest files. Thx – DrewAdams

Thank you! Sorry, should have read more carefully when looking for the source of the latest files…just assumed they’d be in version control. Got the latest version and everything seems to be working perfectly. – Divia


wrong-type-argument stringp nil on completion for text entries

I am receiving a wrong-type-argument stringp nil error while trying to complete the fileset entries for the FileSets function. This does not prevent the completion which does succeed.

The error is only when a completion attempt (either prefix or apropos) is made for a text entry that is NOT a command, function, buffer or a file. For these types, the error does not appear.

The error occurs when I try to invoke `filesets-open' command. The sequence of events is as follows:

  1. I invoke M-x filesets-open
  2. The prompt for filesets is displayed in the minibuffer
  3. I enter the prefix for the fileset to open and press the TAB key
  4. The error message wrong-type-argument stringp nil is displayed in the mini-buffer
  5. I can then press TAB or down again to successfully complete the entry

Backtrace details – The setup is using:

The test was done using emacs -Q and with only Icicles and FileSets enabled (only elisp files, not byte-compiled). Using (setq debug-on-error t), the following backtrace is displayed (the name of the fileset being loaded is “testFileSet”):

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  get-buffer(nil)
  ...
  read-from-minibuffer("Open fileset: " ("" . 1) ...
  completing-read("Open fileset: " (("testFileSet" (:files "d:/workingdir/names.txt"))) nil t)
  filesets-open()
  ...
  call-interactively(icicle-execute-extended-command)

evolve75

I think I fixed that bug on 2007/04/07. Please try the latest, and let me know.

BTW, each Icicles file has its own Update number. In this case, it is the number for icicles-fn.el that is the most important – you need the latest, which is Update #: 10304. Please pick up the latest version of each Icicles Lisp file. Thx – DrewAdams

Hi Drew, I downloaded the latest files (including icicles-fn.el) and confirm that the issue is now fixed. Thanks a lot! – evolve75



The default buffer of ‘icicle-buffer’ and the buffer selected by ‘C-x b RET’ mismatch.

Such as: `C-x C-f TAB C-g', `M-:' (icicle-default-buffer-names), and it echo ("*Completions*" " *Minibuf-1*" "*Completions*" "icicles-mac.el"). `C-x b' , minibuffer will be "+ Switch to buffer (icicles-mac.el): ", input nothing, RET. And "*Completions*" will be selected. This is very strange. <code> BTW, I have set icicle-buffer-no-match-regexp to <code> ^\\ \\|^\\*Ibuffer\\|^\\*Apropos\\|^\\*Backtrace\\|^\\*Completions\\*\\| ^\\*Help\\|^\\*Bookmark\\|^\\*Messages\\|^\\.newsrc-dribble\\| ^\\*Woman-Log\\|^\\*Compilations\\|^\\*Completions\\|^\\*Compile-Log\\| ^\\*Calendar\\|^\\*cscope\\|^\\*grep\\|^\\*BBDB\\|^\\*Tree\\|^\\*Group\\| ^\\*EMMS Playlist\\|^\\*Summary\\ n\\|Map_Sym.txt\\|^\\*w3m\\|^\\#\\| ^\\irc.*:\\|localhost:6668

deftsp

I cannot reproduce the problem as you describe it. However, are you sure that your regexp is the right one? Try using a regexp that filters out only ‘*Completions*’, to see if that works for you, at least.

Note that if you use Customize to set the option value, then do not use double backslashes (`\’) in the value you type in – the value should be just ^\*Completions\*, not ^\\*Completions\\*. After setting the option value using Customize, ‘C-h v’ will show double backslashes. – DrewAdams

I’ll give you more detail:

(setq icicle-buffer-no-match-regexp “^
*Completions
*$”) ; I’m sure this regexp is right, it indeed match buffer *Completions*.

‘C-x C-f TAB C-g’, `M-:’ (icicle-default-buffer-names), Minibuffer echo (”*Completions*” “*Minibuf-1*” “*Completions*” “web-default.ss”).

‘C-x b’, Minibuffer will be “+ Switch to buffer ( *Minibuf-1*): “ , just RET, *Completions* will be select. error happen. I input nothing and default buffer is *Minibuf-1*, RET, *Minibuf-1* should be selected.

Now set icicle-buffer-no-match-regexp to nil, repeat above steps.

‘C-x C-f TAB C-g’, `M-:’ (icicle-default-buffer-names), Minibuffer echo (”*Completions*” “*Minibuf-1*” “*Completions*” “web-default.ss”).

‘C-x b’, Minibuffer will be “+ Switch to buffer ( *Completions*): “ , just RET, *Completions* will be select. It’s normal case.

BTW, I do not use mutil frames. – deftsp

Got it. Should be fixed now; please try the latest. Thx – DrewAdams

Thanks for the fix. – deftsp


‘grep-find’s default prompt is error. For examle, when current direcotry is ~/.emacs.d/packages/icicles, M-x grep-find, mibibuffer will be:

Run find (like this) (~/.emacs.d/packages/icicles/find . -type f -print0 | xargs -0 -e grep -nH -e ): ~/.emacs.d/packages/icicles/find . -type f -print0 | xargs -0 -e grep -nH -e

And cursor will stay at the front of ‘find’.

But when ‘icicle-mode’ is disable minibuffer will be: Run find (like this): find . -type f -print0 | xargs -0 -e grep -nH -e

cursor stay at the end of the line. for Update #: 22415. And previous icicles have no such error.

I found the problem is caused by function ‘icicle-read-shell-command’, it will add current-directory to the front of the initial input. – deftsp

This is a feature, not a bug. Just hit ‘RET’ – the directory is ignored.

As soon as you complete to a command (which is what you are doing here), the directory is removed from the minibuffer. See:

The directory is there because Icicles lets you use file-name completion to navigate to any command file, anywhere. In addition to this file-name completion, command completion is available for commands that Emacs thinks might be appropriate (e.g. ‘find’, in the case you described).

The command completion is similar to what vanilla Emacs provides. What Icicles provides additionally is file-name completion. Known commands as completion candidates are highlighted in ‘*Completions*’ using face ‘icicle-extra-candidate’. They are provided from three possible sources:

1. Associations provided by option ‘dired-guess-shell-alist-user’ (and the automatically provided ‘dired-guess-shell-alist-default’ associations), if you use Dired X (standard library dired-x.el).

2. MIME-type associations (starting with Emacs 23).

3. Commands recognized by your search path, if option ‘icicle-guess-commands-in-path’ is non-‘nil’.

Candidates from all of these sources are treated the same way:

  • Each is highlighted in ‘*Completions*’ with face ‘icicle-extra-candidate’ – easy to distinguish from a file name.
  • If you complete to such a command, the default directory disappears from the minibuffer.

This is spelled out in the doc and doc strings. For example, hit `C-h k M-!’, then click the link to see the doc string of ‘icicle-read-shell-command-completing’. – DrewAdams

command completion is a cool feature.

But to the ‘grep-find’, the variable ‘grep-find-command’ default value is find . -type f -print0 | xargs -0 -e grep -nH -e . When I execute ‘grep-find’, Minibuffer will be: find (like this) (~/.emacs.d/packages/icicles/find . -type f -print0 | xargs -0 -e grep -nH -e ): ~/.emacs.d/packages/icicles/find . -type f -print0 | xargs -0 -e grep -nH -e .

Cursor stay at the front of find, because the default ‘grep-find-command’ is good enough, I just ‘C-e’, cursor will go to the end of the line, and input something I need to grep them in all files in current directory. But Shell will treate `~/.emacs.d/packages/icicles/find’ as a shell command, error happen. – deftsp

I see the problem now, and I’ll think about a solution (but not before the weekend). Until a solution is available, you can at least turn off Icicles treatment for reading shell commands (and other things) by customizing option `icicle-redefine-standard-commands-flag’ to ‘nil’. If you do that, then Icicle mode will not substitute any Icicles commands for standard commands. – DrewAdams

Please try the latest. I decided to just punt and call the vanilla function when the INITIAL-CONTENTS argument is non-‘nil’. – DrewAdams

Works great … thanks for the fix. – deftsp


Command ‘icicle-buffer’ use (another-buffer nil t) or (other-buffer (current-buffer)) as default prompt. When last buffer is ‘*Completions*’, ‘C-x b RET’ will select buffer ‘*Completions*’. Most of the time, switch to buffer ‘*Completions*’ is useless.

More worse (another-buffer nil t) or (other-buffer (current-buffer)) will ingore the the variable ‘icicle-buffer-no-match-regexp’. – deftsp

I fixed the latter part: ‘icicle-buffer-no-match-regexp’ now affects the default choice. Please try the latest icicles-cmd.el.

However, I’m not convinced that ‘*Completions*’ should be singled out for special treatment here. Icicles behaves the same as vanilla Emacs in this regard: If ‘*Completions*’ is the last buffer you accessed, then it will be the default choice.

It’s very unusual, BTW, if ‘*Completions*’ is the last buffer you access. Can you provide a specific recipe for how that happens to you? – DrewAdams

For example, I use ‘C-x C-f’ to find a file and press ‘TAB’, buffer ‘*Completions*’ is created then I press ‘C-g’. The result is that buffer ‘*Completions*’ is the last buffer I access.

I agree ‘*Completions*’ should not be singled out for special treatment here. But if someone do not like ‘Completions’ to be selected, icicle can satisfy her too like your fix.

I notice a problem, the define of function ‘icicle-default-buffer-name’ in icicles-cmd.el. The last argument of ‘memq’ is a LIST, but ‘icicle-buffer-no-match-regexp’ is not.

(defun icicle-default-buffer-name ()
  "Default buffer name."
  (let ((bufname  (buffer-name (if (fboundp 'another-buffer) ; In `misc-fns.el'.
                                   (another-buffer nil t)
                                 (other-buffer (current-buffer))))))
    (and (not (memq bufname icicle-buffer-no-match-regexp)) bufname)))

deftsp

Oops; how silly. Sorry about that. Please try it again with the latest versions of icicles-cmd.el and icicles-fn.el.

Actually, it never occurred to me before to filter the default value(s) using the Icicles global filters (Icicles - Global Filters), but I guess it’s a good idea. I’ve added that generally now, for ‘completing-read’ and ‘read-file-name’, not just for buffer names.

BTW, I never see ‘*Completions*’ as the default after ‘C-x C-f TAB C-g C-x b’. I guess because I use a separate frame for ‘*Completions*’. I had to start with emacs -Q to reproduce that. – DrewAdams

I add ^\\*Completions\\* to icicle-buffer-no-match-regexp. After ‘C-x C-f TAB C-g C-x b’, the mibibuffer is + Switch to buffer: , no default buffer. How about use the buffer before ‘*Completions*’ as default buffer. I guess it can be get from buffer history.

Thanks for your fix. – deftsp

The short answer: No, you’ll have to get it from the history (‘M-p’).

This is not a buffer thing; it’s general. The minibuffer now respects Icicles global filtering for the default value(s), as well for completion candidates. At this level (‘read-from-minibuffer’), there is no notion of “the buffer before ‘*Completions*’ or even of buffers.

However, if you use Emacs 23, then there can be multiple default values. Vanilla Emacs appends all buffers to the list of default values (which are available via ‘M-n’) – which is silly, IMO. Icicles keeps just the first four. So with Icicles and Emacs 23, you will likely get a default value even after filtering. To see this, you will need the latest files. – DrewAdams

Oh, It works. Thanks for all your done. – deftsp


I am having problems loading icicles. I get: fset: Symbol’s function definition is void: dired-smart-shell-command, when I do M-x load-library RET icicles RET. I am using Emacs 22.2.1 on Ubuntu…thanks! – host86-161-251-19.range86-161.btcentralplus.com

Sorry about that – should be fixed now. Please try the latest and let me know. Thx – DrewAdams

All working now! Thanks!


With „GNU Emacs 23.0.60.13 (i686-pc-linux-gnu, GTK+ Version 2.12.11) of 2008-12-31“ and Icicles from right now, I have a problem with Icicles - Programming with Fancy Candidates: I eval (completing-read "Package: " '("one" "two" "three") nil t nil), type one RET, and I got #("one" 0 3 (face nil)). I expected just "one" since no one of the 3 conditions for the activation of fancy candidates was met. While debugging, I found that icicle-fancy-cands-internal-p is set to nil; however, icicle-unpropertize-completion-result-flag is still nil.

This causes problems with SlimeMode from CVS: pressing , to activate the minibuffer command, then !p RET, then selecting a package will fail (function: slime-repl-set-package). Maybe Slime should unpropertize this text, but since (face nil) is anyway useless, Icicles could also not add it. --DanielClemente

Sorry, Daniel, I didn’t notice your bug report here until today. It’s always quicker and more sure to use ‘M-x icicle-send-bug-report’ (or menu item Icicles > Send Bug Report).

Anyway, this should be fixed now. Please download the latest icicles-mcmd.el. Let me know if you still see the problem. Thx – DrewAdams

Yes, now it works. No problem for the wait. Thanks; DanielClemente


Icicles and ‘grep-find’. icicles version: Update #: 22376 (2.12.2008). Emacs version: GNU Emacs 23.0.90.1 (x86_64-pc-linux-gnu) of 2009-02-08

 M-x: icicle-mode
 M-x: grep-find

Echo: file-name-extension: Wrong type argument: stringp, nil

I trace this bug. Finally, I got it. In function icicle-read-shell-command, the third line from the end. “(mailcap-file-default-commands (list default-value))”, If no vaule given to default-value. It will be (mailcap-file-default-commands (nil)), and file-name-extension will complain. How about change it to (mailcap-file-default-commands default-value).

I’m having problems with ‘icicle-read-shell-command’ with ‘default-value’ being nil in two cases. With compile in any buffer and with shell-command on non-file buffers. Both cases were getting me a Wrong parameter type: stringp, nil error. I’ve made a quick fix ‘or’ing each ocurrence of default-value with an empty string. But the result is bad: the prompt appears like . Compile Command (): with those ugly empty parens. I don’t know if it’s really an issue or it’s just me and it’s my first time posting here, so sorry if I wasted anybody’s time. BTW, emacs version is GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of 2009-01-15 on LENNART-69DE564. – KaoFelix

Thanks for the report. Should be fixed now. Please try the latest icicles-fn.el. If you still have a problem, let me know. – DrewAdams

It’s working perfectly for me now. Many thanks! --KaoFelix


old-shell-dynamic-complete-filename is void with Debian’s emacs22

I had to apply the following so I could load icicles on sid’s current emacs22 (22.2+2-5):

: diff -u -r icicles.bak/icicles-cmd.el .emacsd/icicles/icicles-cmd.el
: --- icicles.bak/icicles-cmd.el  2008-12-27 15:45:40.000000000 -0800
: +++ .emacsd/icicles/icicles-cmd.el      2008-12-28 21:36:20.000000000 -0800
: @@ -867,9 +867,9 @@
:   ;;
:   ;; Uses Icicles completion when there are multiple candidates.
:   ;;
:  -(eval-after-load "shell"
:  -  '(or (fboundp 'old-shell-dynamic-complete-filename)
:  -(fset 'old-shell-dynamic-complete-filename (symbol-function 'shell-dynamic-complete-filename))))
:  +;;(eval-after-load "shell"
:  +;;  '(or (fboundp 'old-shell-dynamic-complete-filename)
:  +;;(fset 'old-shell-dynamic-complete-filename (symbol-function 'shell-dynamic-complete-filename))))
:  
:    ;;;###autoload                                                                   
:    (defun icicle-shell-dynamic-complete-filename ()                                 

Is the current icicle only supposed to work with emacs23? – SebastianLuque

Should be fixed now. Please try the latest and let me know. Thx – DrewAdams

Thank you very much; by the way, I have no clue how emacswiki expanded my Seb to SebastianLuque 😊 --SebastienDelafond

That was my fault. I handled a different bug from Seb Luque around the same time, and figured it must have been him. Sorry about that. – DrewAdams


Perhaps due to changes in minibuffer completion for new files ([1]), Icicles is not allowing me to open new files. Using Emacs 23 from today (21-12-2008) and Icicles from today (icicles.el #22312), and this .emacs:

    (add-to-list 'load-path "~/.emacs.d/icicles/") (require 'icicles) (icy-mode 1)

Do this:

Then „No prefix completions“ appears (even if you press ENTER more times) and you cannot open that new file. ENTER works, however, in C-x C-w for an unexisting name. M-x unexisting ENTER does nothing.

Debugging it, I saw that no (cond) in (icicle-minibuffer-complete-and-exit) was true until the last (t (icicle-display-candidates-in-Completions)), which ran. – 21-dec-2008, DanielClemente.

Should be OK now; closing the bug. Let me know if you still see a problem. (They changed the Emacs 23 code more than once during the course of that thread.) Thx for the report. – DrewAdams

With your changes, C-x C-f /etc/fstab2 RET works correctly (it opens a new file); thanks. However, C-x C-f /etc/fst RET opens directly /etc/fstab (wrong). – DanielClemente

Sorry about that. Please try again. Thx – DrewAdams

It now works very well. Thanks – DanielClemente


Hello, here is a small patch to automatically trigger an action when the explorer has only one match. This is pretty handy when using icicle-find-tag to jump to tags at point. I guess there is a bug in defun icicle-first-matching-candidate since it returned the value from string-match which is then used in icicle-get-alist-candidate as if it were an element of the candidates list. Not sure though it’s from my first journey with edebug 😊

--- icicles/icicles-cmd.el      2008-11-08 00:58:02.000000000 +0100
+++ ../icicles/icicles-cmd.el   2008-11-09 09:22:35.000000000 +0100
@@ -1696,19 +1695,24 @@
         result)
     (setq icicle-act-before-cycle-flag      nil
           icicle-candidates-alist           nil
-          icicle-explore-final-choice       ""
+          icicle-explore-final-choice       nil
           icicle-explore-final-choice-full  nil)
     (icicle-highlight-lighter)
     (message "Finding candidates...")
     (when define-candidates-fn (funcall define-candidates-fn))
-    (unless icicle-candidates-alist (error "No candidates defined"))
+    (unless icicle-candidates-alist 
+      (error "No candidates defined"))
+    (if (= (length icicle-candidates-alist) 1) 
+       (setq icicle-explore-final-choice (caaar icicle-candidates-alist)))
     (unwind-protect
          (condition-case failure
              (progn
-               (setq icicle-explore-final-choice
-                     (apply #'completing-read prompt icicle-candidates-alist compl-read-args))
+               (unless icicle-explore-final-choice 
+                (setq icicle-explore-final-choice
+                     (apply #'completing-read prompt icicle-candidates-alist compl-read-args)))
                (setq icicle-explore-final-choice-full
-                     (icicle-get-alist-candidate icicle-explore-final-choice 'no-error-p))
+                     (icicle-get-alist-candidate icicle-explore-final-choice nil))
                (unless icicle-explore-final-choice-full (error "No such occurrence"))
                (setq result  (if final-action-fn
                                  (funcall final-action-fn)

--- icicles/icicles-fn.el       2008-11-08 00:47:12.000000000 +0100
+++ ../icicles/icicles-fn.el    2008-11-09 08:40:17.000000000 +0100
@@ -3903,14 +3901,16 @@
     (if (null candidates)
         (setq res nil)
       (while (and candidates (not res))
-        (setq res         (if (consp (caar candidates)) ; Multi-completion candidate
-                              (save-match-data
-                                (string-match (regexp-quote cand)
-                                              (concat (mapconcat #'identity (caar candidates)
-                                                                 icicle-list-join-string)
-                                                      icicle-list-end-string)))
-                            (equal cand (caar candidates)))
-              candidates  (cdr candidates))))        
+        (if (consp (caar candidates)) ; Multi-completion candidate
+           (save-match-data
+             (if (string-match (regexp-quote cand)
+                               (concat (mapconcat #'identity (caar candidates)
+                                                  icicle-list-join-string)
+                                       icicle-list-end-string)) 
+                 (setq res (car candidates))))
+         (if (equal cand (caar candidates)) 
+             (setq res (car candidates))))
+         candidates  (cdr candidates)))        
     res))
 
 (defun icicle-completing-p ()

HannesJanetzek

Those are two independent patches: a bug fix and a suggestion. Both are good. Thx. I applied both, but I implemented the completion bypass suggestion a bit differently. (Things are more complex, because of the possibility of multi-completions etc.)

However, I have not yet removed (changed to ‘nil’) the ‘no-error-p’ arg in the call to ‘icicle-get-alist-candidate’. Can you tell me why you propose that change? Thx - DrewAdams

Oh just ignore that no-error-p thing, it’s a leftover from my first clueless efforts. And thanks for including the changes. Best Regards, HannesJanetzek


After updating all icicles*.el files, just inserting or removing a single chracter in a minibuffer finish after a noticeable delay. Especially if I long-press some key, emacs does not respond for a while and the result is suddenly updated after some seconds. I binary-searched the emacswikicode CVS and found that the delay occurs since the version of 2008-02-01 of icicles.

All ‘Upgrade #’s of the version, one day before 2008-02-01 and has no delay, are:

And ‘Upgrade #’s of the 2008-02-01 version are:

I am using GNU Emacs 23.0.0.1 (i386-mingw-nt5.1.2600) of 2007-06-20 on TPAD. Well, actually I suspect this might not be a bug and might be an inevitable delay for other some improved feature. In that case, I should consider upgrading my old Tualatin Celeron 😟. – ThomasLim

Thanks for your report, Thomas, and for the effort of trying to track this down. I suspect that the slowdown comes from the code that highlights non-matching input. Please take a look at Icicles - Icompletion#HighlightNonmatch. Try setting some of the options described there.

As a first test try setting ‘icicle-highlight-input-completion-failure’ to ‘nil’. If you do not see an improvement with that, then the non-match highlighting is not the problem. Let me know if this highlighting is indeed the problem, and whether you have found a reasonable solution by customizing the options.

I think this highlighting is a very useful feature, but it can be costly. Essentially, it retests your input for each char you type or delete. And when it checks your input it checks multiple subsets (prefixes) of your input, to determine the place where the non-match begins. At least it does the latter using a binary search, but the whole operation is still costly.

Note the special mention about remote files. Testing remote file-name input is really a killer, because each attempt to see if part of your input matches entails a remote machine access. I’ve done what I could to provide option values to work around this, but the potential problem is always there. Using the toggle `C-^’ to temporarily turn off remote-file checking can help here.

I suspect that the default value of ‘icicle-highlight-input-completion-failure’ is bad for you, and that customizing that option will give you good performance. Let me know. Sometimes I think I will change the default value, but I haven’t yet. Perhaps you have a suggestion about the default? I prefer not to turn this feature off, because some users tend not to learn about options unless they run into a problem. ;-) I tell myself it’s better to at least let people see this feature up front, and then they will learn that they can modify or remove it, if they have performance problems. – DrewAdams

Thank you for your answer. Setting ‘icicle-highlight-input-completion-failure’ to ‘nil’ seems to decrease the delay a little bit but not that much (only 10~20% as far as I feel). I entered C-x C-f (‘icicle-file’) and long-pressed any alphabet key for some seconds. – ThomasLim

Then I’m afraid I don’t know what to suggest, without more info. If you could use the debugger to find out where the time is being spent, then I could perhaps act accordingly. I’d like to help, but I will need more info.

Can you characterize when it happens? Does it matter whether minibuffer input is read with or without completion? (E.g. try (read-from-minibuffer "Some prompt: "), which does not use completion.) Does it matter whether it is file-name completion or some other completion (e.g. ‘C-x C-f’ versus ‘C-x b’)?

If the problem occurs only for ‘M-x’ (command completion), then try customizing ‘icicle-top-level-key-bindings’ to remove the mapping of ‘execute-extended-command’ to ‘icicle-execute-extended-command’.

From your description, the problem should go away if you use `C-#’ to turn off (toggle) incremental completion. Does it? Every bit of info helps, but turning off incremental completion doesn’t fix the problem, of course. ;-)

Please let me know whatever you can find out – the more the better. Thanks – DrewAdams

Also, and perhaps most importantly, can you please test with a different Emacs version, preferably Emacs 22? You are using Emacs 23, and a very old version of that. Emacs 23 is not stable, and it is difficult to debug Icicles against a moving target. And it is likely that I cannot reproduce what you see on an intermediate development version from 2007. Thx – DrewAdams

Emacs 22 (GNU Emacs 22.1.50.1 (i386-mingw-nt5.1.2600) of 2007-08-19 on TPAD) has delay too. However I found something suspicious about the callstack when I quit (‘C-g’) during the delay:

Debugger entered--Lisp error: (quit)
  call-process("D:/tools/emacs/ntemacs22/bin/cmdproxy.exe" nil nil nil "-c" "NET USE d:")
    (condition-case nil (call-process shell-file-name nil nil nil
     shell-command-switch (concat "NET USE " ...)) (error nil))
    (eq 0 (condition-case nil (call-process shell-file-name nil nil
     nil shell-command-switch ...) (error nil)))
    (and (string-match "\\`\\([a-z]:\\)" file) (eq 0 (condition-case nil ... ...)))
    (let ((case-fold-search t)) 
    (and (string-match "\\`\\([a-z]:\\)" file) (eq 0 ...)))
    (and (eq system-type (quote windows-nt)) (let (...) (and ... ...)))
    (or (and (eq system-type ...) (let ... ...)) (and (fboundp ...)
     (ffap-file-remote-p file)) (and (fboundp ...) (file-remote-p file)))
  icicle-file-remote-p("d:/tools/emacs/emacsw")
    (not (icicle-file-remote-p icicle-current-input))
    (or tested-remote-p (not (icicle-file-name-input-p))
   (not (icicle-file-remote-p icicle-current-input)))
    (and icicle-incremental-completion-p (or tested-remote-p (not ...)
     (not ...)) (or (get-buffer-window "*Completions*" 0) (not ...)) 
   (let (...) (or ... ...)))
     (if (and icicle-incremental-completion-p (or tested-remote-p ... ...)
         (or ... ...) (let ... ...)) (progn (let ... ... ...)))
     (when (and icicle-incremental-completion-p (or tested-remote-p ... ...) 
     (or ... ...) (let ... ...)) (let (...) (funcall ...) (run-hooks ...)))
   (let ((tested-remote-p ...))
     (when (and icicle-incremental-completion-p ... ... ...)
       (let ... ... ...)))
      (if (< (length icicle-current-input)
       icicle-Completions-display-min-input-chars)
     (save-selected-window (icicle-remove-Completions-window))
     (let (...) (when ... ...)))
     (progn (apply fn args)
          (setq icicle-current-input icicle-minibuffer-contents-from-minibuffer)
                icicle-input-fail-pos nil) 
        (when (overlayp icicle-complete-input-overlay)
          (delete-overlay icicle-complete-input-overlay))
          (icicle-highlight-initial-whitespace icicle-current-input) 
          (if (< ... icicle-Completions-display-min-input-chars)
             (save-selected-window ...)
           (let ... ...))
             (setq mark-active nil))
             (unwind-protect 
               (progn (apply fn args)
                      (setq icicle-current-input
                      ... icicle-input-fail-pos nil) (when ... ...) 
                      (icicle-highlight-initial-whitespace icicle-current-input)
                      (if ... ... ...)
                        (setq mark-active nil)) 
                       (set-match-data save-match-data-internal (quote evaporate)))
            (let ((save-match-data-internal ...)) 
              (unwind-protect (progn ... ... ... ... ... ...) 
               (set-match-data save-match-data-internal ...)))
               (save-match-data (apply fn args) 
               (setq icicle-current-input 
                   (icicle-minibuffer-contents-from-minibuffer)
                   icicle-input-fail-pos nil) 
               (when (overlayp icicle-complete-input-overlay) 
                   (delete-overlay icicle-complete-input-overlay))
              (icicle-highlight-initial-whitespace icicle-current-input) 
              (if (< ... icicle-Completions-display-min-input-chars) 
                  (save-selected-window ...)
                (let ... ...)) 
                  (setq mark-active nil))
  icicle-call-then-update-Completions(delete-backward-char 1 nil)
  icicle-delete-backward-char(1 nil)
  call-interactively(icicle-delete-backward-char)
  old-read-file-name(#("+  File or directory:  (<S-tab>, TAB: list, C-?: help)   
       " 0 1 nil 1 2 (face icicle-completing-prompt-prefix) 
       2 3 nil 3 22 (face minibuffer-prompt) 22 55
       (face icicle-prompt-suffix) 55 57 nil) 
       nil "d:/tools/emacs/emacswikicode/" nil nil nil)
  (catch (quote icicle-read-top)
   (old-read-file-name icicle-prompt dir default-filename
     require-match initial-input predicate))
   (setq result (catch (quote icicle-read-top) 
      (old-read-file-name icicle-prompt dir default-filename
        require-match initial-input predicate)))
       (condition-case nil (setq result (catch ... ...)) 
        (wrong-number-of-arguments (setq result ...)))
      (let ((minibuffer-prompt-properties ...)) 
        (condition-case nil (setq result ...)
         (wrong-number-of-arguments ...)))
    (cond ((not icicle-mode) (setq icicle-prompt prompt) 
           (condition-case nil ... ...))
          ((or ... ... ...) (setq icicle-prompt ...) (let ... ...))
          (t (setq icicle-prompt ...) (let ... ...)))
   (let* ((completing-prompt-prefix-symb ...)
          (completing-prompt-prefix ...) result)
     (cond (... ... ...) (... ... ...) (t ... ...)) 
     (when require-match (icicle-remove-Completions-window)) result)
  icicle-read-file-name-1("File or directory: " nil 
      "d:/tools/emacs/emacswikicode/" nil nil nil)
  (setq result (icicle-read-file-name-1 prompt dir default-filename
                  require-match initial-input predicate))
  (let* ((ffap-available-p ...) (fap ...)
         (mouse-file "*mouse-2 file name*")
         (icicle-proxy-candidates ...) temp result) 
    (setq result (icicle-read-file-name-1 prompt dir
                   default-filename require-match initial-input predicate)) 
    (when ffap-available-p (cond ... ...))
    (when (setq temp ...) (setq result ...)) result)
  (unwind-protect (let* (... ... ... ... temp result)
     (setq result ...) 
     (when ffap-available-p ...) (when ... ...) result) 
     (setq icicle-proxy-candidates nil))
  read-file-name("File or directory: " nil "d:/tools/emacs/emacswikicode/" nil nil nil)
  (if (< emacs-major-version 21)
      (read-file-name "File or directory: " nil
           (if ... ... default-directory) nil nil) 
    (read-file-name "File or directory: " nil 
         (if ... ... default-directory) nil nil nil))
  (let ((file-choice ...))
    (setq icicle-candidate-action-fn nil)
    (funcall (quote icicle-find-file-w-wildcards) file-choice))
    (condition-case act-on-choice
      (let (...)
        (setq icicle-candidate-action-fn nil)
        (funcall ... file-choice))
      (quit (icicle-try-switch-buffer orig-buff) nil)
      (error (icicle-try-switch-buffer orig-buff) nil (error "%s" ...)))
  (let* ((orig-buff ...) (orig-window ...)
         (icicle-delete-candidate-object ...)
         (icicle-candidate-action-fn ...)) nil 
    (condition-case act-on-choice
      (let ... ... ...) (quit ... nil) (error ... nil ...)) nil)
  icicle-find-file()
  call-interactively(icicle-find-file)

The detail of the callstack changes for each trial but the topmost entry is always "NET USE:" thing. I recall what you had mentioned regarding remote files before. But there is, as far as I know, no remote file involved here: the emacs binaries, all the `*.el’ files and the working directory are in my local disk. To answer your other requests, `C-#’ during ‘C-x C-f’ seems to decrease the delay a little bit but not that much. Weird thing about `C-#’ is that the callstack does not show up when I quit during the delay even if debug-on-quit is set as t.

‘C-x b’ nor (read-from-minibuffer "Some prompt: ") do not have delay. I need more time to inspect if ‘M-x’ also became slower. I regert that I should have been more specific in my earlier report 😊 Thanx. – ThomasLim

Thanks for the update. Could you please try with a regular Emacs release. AFAIK, Emacs 22.1.50.1 is not Emacs 22; it is a very old development version of Emacs 23 (the “50” indicates that). Please try with the normal Emacs release 22.1 or 22.2, for instance.

I can also tell (from the prompt, which still uses “(<S-tab>, TAB: list, C-?: help"), that you are using a very old version of Icicles. Please use the latest version – that is the only version that I debug and fix.

So far, it seems from what you say that the delay occurs only for file-name completion, which confirms what I was saying about non-match highlighting, incremental completion, and remote file testing. But you say that turning off incremental completion (`C-#’) makes no difference, which surprises me. I don’t understand how you can see a slowdown when `C-#’ is toggled off.

Oops, maybe I do see. Please try the latest icicles-fn.el. I just fixed a bug while checking the code: I had a typo that prevented `C-#’ from turning off non-match highlighting when ‘icicle-highlight-input-completion-failure’ has its default value of ‘implicit’. The code was testing for a (non-existent) value of ‘implicit-remote’, not ‘implicit’ as it should. With the fix, toggling incremental completion off should turn off input mismatch highlighting.

Another thing you can try is setting ‘icicle-test-for-remote-files-flag’ to ‘nil’ – that tells Icicles that all the files you are using are local, so there is no need to check for remote file-name syntax. See if that makes a difference. However, that should be turned off anyway if you toggle `C-#’ off.

The system call to NET USE is normal, if you are on MS Windows. Are you saying that that is causing a significant delay? That would be interesting to know. It should be quick; its purpose is to check whether a given drive is a network drive or local. The aim is to avoid accessing a network drive (mapped drive) because such (quasi-)remote access can take time.

I don’t know what else to tell you at this point. The main thing is to test with up-to-date Icicles files and a real Emacs release. It’s impossible to tell anything with an Emacs 23 development version. And they are changing things as we speak wrt reading file names in Emacs 23 because of performance problems. For purposes of testing Icicles, just avoid Emacs 23 until it is released. – DrewAdams

I’ve tried GNU Emacs 22.3.1 (i386-mingw-nt5.1.2600) of 2008-09-07 on SOFT-MJASON (This must be regular release and new, right?) which shows the same delay. And with up-to-date icicles, `C-#’ removes the delay. And setting ‘icicle-test-for-remote-files-flag’ to ‘nil’ also removes the delay! (Before updating, I was using old icicles that are from 2008-2-1 CVS that showed this kind of delay for the first time as I mentioned before.)

I think NET USE must be responsible for the delay because when I randomly abort during the delay, I always see NET USE at the top of the callstack. NET USE seems to be called at every character insert/delete. Isn’t it sufficient to run NET USE only when the first 1 or 2 characters, that determines the drive, has changed? Or how about calling it once and reusing the first test result next time? – ThomasLim

OK, good; now we’re back to square 1 ;-). Just to be sure you understand: `C-#’ or ‘nil’ ‘icicle-test-for-remote-files-flag’ just side-steps the issue. `C-#’ prevents incremental completion altogether, which you probably do not want to do most of the time. ‘icicle-test-for-remote-files-flag’ prevents use of remote files and tells Icicles that you are using only local files, so, again, you probably do not want to do that most of the time.

Coming back to the beginning, the proper thing to adjust for this is option ‘icicle-highlight-input-completion-failure’ (and perhaps its brothers, ‘icicle-highlight-input-completion-failure-delay’ and ‘icicle-highlight-input-completion-failure-threshold’). Please try customizing this (without saving your customizations).

Try first choosing item Never (= Lisp value ‘nil’) in the Customize Value Menu. That should do the same thing as what you saw for `C-#’ and for ‘nil’ ‘icicle-test-for-remote-files-flag’, but without preventing incremental completion.

Then try each of the other values in the menu, in order – the order is from least permissive to most. For example, choosing item Explicit (‘TAB’/‘S-TAB’) strict completion (= Lisp value ‘explicit-strict’) will highlight input non-matches only when you hit ‘TAB’ or ‘S-TAB’, and only when completion is strict (which excludes file-name completion, which is lax). One of these values should give you behavior you like.

I believe that there is a problem with NET USE on your machine. I’m no expert on this area, but you might want to test a bit with or without Emacs (and Icicles). A call to NET USE should be very quick. It involves no access of mapped drives; it simply checks in a local value whether a given drive is mapped to a network drive or is local. I believe something is wrong in your case.

I’m afraid that your suggested improvements would be inappropriate, because minibuffer input can be virtually anything. It would not be easy to reliably determine what is reference to a Windows drive and what is not (it need not be the input prefix). And the whole idea of incremental completion is that the completion candidates are updated on the fly when you change, yes, a single character anywhere in the input.

I am open to suggestions, but I believe so far that the code does about the best that can be done. The right approach, I think, is for users to be aware of the possibilities and adapt them to their own use cases. This is why there are several options and several option values. And this is why there are convenient toggle keys for incremental completion and testing for remote files (`C-#’ and `C-^’, respectively). The user is the best one to master this, IMO – the code should not try to be too smart.

But, as I say, I’m open to concrete and informed suggestions – I just ask that the existing design be understood and tried first. And I am especially open to (1) changing the default value of ‘icicle-highlight-input-completion-failure’ (perhaps to ‘explicit-strict’?) and (2) improving the doc. Suggestions welcome.

I’ve kept the default value as ‘implicit’ because (1) I think that it should work well for most people and (2) it lets new users see that such highlighting is possible.

If I change the default value to, say, ‘explicit’, then many users will not know that the same feature is available for incremental completion. Similarly, if I change it to, say, ‘implicit-strict’, many users will not know that the highlighting is also available for lax (e.g. file-name) completion. Many (most?) users don’t read the doc well (or at all), so default values are very important. On the other hand, if there are a significant number of users for whom a value such as ‘implicit’ causes a long delay, then that is even worse, because many of them will not know that (or how) they can change this.

As I say, suggestions welcome. And if you do get to investigate further why NET USE causes a delay for you, please let me know. Thanks for your help. – DrewAdams

First of all, setting ‘icicle-highlight-input-completion-failure’ to ‘nil’ does not remove the delay at all. In my case, every NET USE D: call takes up to 400ms which is very expensive for entering just one character. (Is it only me who experience this problem?) When you delete 10 characters, at least 10 NET USE D: processes are invoked. The result of NET USE D: will not change nor need to be checked so frequently. I think the results of NET USE C:, NET USE D:… can be saved in a hash table and can be used later without invoking another NET USE process, so called memoizing approach, as shown below:

(defvar remote-drive-hash (make-hash-table :test 'equal))

(defun check-remote-drive (drv)
  (let ((lookup (gethash drv remote-drive-hash 'no-assoc)))
    (if (equal lookup 'no-assoc)
	(puthash drv 
		 (call-process shell-file-name nil nil nil shell-command-switch
			       (concat "NET USE " drv)) remote-drive-hash)
      lookup)))

(defun icicle-file-remote-p (file)
  "Non-nil means FILE is likely to name a file on a remote system.
For MS Windows, this includes a file on a mapped network drive.
Otherwise, this uses `ffap-file-remote-p' and `file-remote-p' (if
defined)."
  ;; $$$$  (save-match-data        ; $$$$$ IS THIS NEEDED?
  (if (and (eq system-type 'windows-nt)
           (let ((case-fold-search  t)) (string-match "\\`\\([a-z]:\\)" file)))
      (eq 0 (condition-case nil
                (check-remote-drive
		 (match-string 1 file))
              (error nil)))
    (or (and (fboundp 'ffap-file-remote-p) (ffap-file-remote-p file))
        (and (fboundp 'file-remote-p) (file-remote-p file)))))

You worry about the minibuffer input can be virtually anything but this delay problem seems to be restricted to ‘icicle-read-file-name’. – ThomasLim

You are absolutely right on all accounts. I’ve incorporated your fix, assuming that’s all right with you. I also made another improvement to avoid a redundant call to ‘icicle-file-remote-p’ when ‘icicle-highlight-input-noncompletion’ has already called ‘icicle-file-remote-p’ and determined that the file is local. Thx for the feedback and fix.

I also changed the default value of ‘icicle-highlight-input-noncompletion’ to ‘implicit-strict’, so file-name input is no longer highlighted by default. I hate to do this, because I think this feature is especially useful for file names, but it’s not worth scaring people away who might see poor performance and never find out about customizing the option.

Please try the latest files and let me know.

BTW, by “virtually anything”, I meant that minibuffer file-name input can have text prefixing a drive letter, so it would be difficult to parse it reliably. I was thinking of stuff preceding ‘/’ or `~’, but I was mistaken that that is a problem here. And anyway the code already relies on matching the drive letter as the prefix.

Let me know if you do find out why NET USE is slow for you – I’m curious. It’s instantaneous for me, and I have both local drives and mapped network drives.

DrewAdams


After executing ‘icy-mode’, ‘ediff-read-file-name’ works in a different way:

 C:\ runemacs -Q --debug-init
 (add-to-list 'load-path "d:/emacs/site-lisp/emacswikicode/")
 (require 'ediff)
 (require 'icicles)
 (message (ediff-read-file-name "hello:" "d:/" "log"))
 ;; I typed in d:/views/bigbang/log, and it returns d:/views/bigbang/log
 (icy-mode)
 (message (ediff-read-file-name "hello:" "d:/" "log"))
 ;; I typed in d:/views/bigbang/log, but it returns d:/log

I am using GNU Emacs 23.0.0.1 (i386-mingw-nt5.1.2600) of 2007-08-19 on TPAD, and icicles pulled from CVS yesterday. (#22200) – ThomasLim

It’s a good bug. I don’t have time right now to tackle it, but I’ve reverted temporarily to a previous behavior that didn’t have this bug. Pick up the latest icicles-mcmd.el. This is a temporary workaround only. After I fix it for real, I will ask you to please test again. Thx – DrewAdams

Should be OK now. Please pound on it, to see. Try ‘RET’ in the minibuffer in various contexts. Let me know if you see a problem. Great bug, thx – DrewAdams


Thanks for all the work on icicles. I used it fairly often at my previous job and am setting it up for better use in my current job. I can’t perform the last bullet point on page Icicles - Large Candidate Sets about not displaying a large candidate set after computing it. When I do ‘C-u icicle-locate-file’ it asks for a directory. Now if I do ‘C-M-Tab’ it does compute a set without displaying it but it does not recurse subdirectories. How do I get it to recurse? – Kartik

Hi Kartik. It should work, but perhaps you are expecting something different from what the explanation tries to say. I just checked, and it works for me at least, on MS Windows.

This is what should happen: ‘C-u M-x icicle-locate-file’ asks for the base directory, which you provide. From then on, you are completing against absolute file names (i.e. including directories) that have the base directory as a prefix. For example, if the base directory is /foo/bar, then the completion candidates would include things like this (assuming they exist):

 /foo/bar/
 /foo/bar/fifi.el
 /foo/bar/titi/
 /foo/bar/titi/tata.el
 /foo/bar/titi/tutu.el
 /foo/bar/toto.el

If you then hit ‘TAB’ or ‘S-TAB’, you will see these candidates in ‘*Completions*’. You can type more prefix text, say /foo/bar/ti, and hit ‘TAB’ again to see that completed to /foo/bar/titi/. Or you can use a regexp with ‘S-TAB’: e.g. /foo/bar/ti../ta will complete to /foo/bar/titi/tata.el.

If you use ‘C-M-TAB’ or ‘C-M-S-TAB’ instead of ‘TAB’ or ‘S-TAB’, the result should be exactly the same, except that the candidates are not displayed in ‘*Completions*’. It might be a bit harder to follow, since you do not see the set that you are completing against, but the result should be exactly the same. Try it first using ‘TAB’ and ‘S-TAB’, to see if that at least does what you expect.

If you do find that you get different completion results for the ‘C-M-’ keys, then please post a recipe to reproduce the problem in detail (file names, keys you hit, etc., leaving nothing out). Perhaps there is a bug, but I don’t see it yet. I suspect that if there is a bug, you will also see the same problem for ‘TAB’ and ‘S-TAB’, so start with those.

FWIW, I don’t use the ‘C-M-’ completion keys much, myself. I like to see the candidates in ‘*Completions*’. I mention this feature because it can save a little display time. However, if time is really of the essence, more time can be saved by creating persistent sets of file names that target the files you want.

That is, you can have several saved completion sets, each of which represents a given set of files (absolute locations) – part of a project, say. Then, instead of completing against all the files on your hard disk, you would complete against the right project or project part. IOW, Icicles - Persistent Completions is your friend. Persistent sets not only offer convenience – retrieve a set at any time by name, without re-specifying each time how it is defined, but they also save time: the set of names is just retrieved instead of calculated.

I do sometimes use my entire file system as a set of completion candidates – and that is one of my persistently saved candidate sets. But when I can, I use a narrower target. Usually, I have some idea where a file is located, and that knowledge can save time over a brute-force search.

Note, BTW, that you can now locate a file using its modification date, in addition to matching its name and location: Icicles - Locate Files by Date. Note too that you can define a set that includes specific files or directories located anywhere, by building it up in pieces – see Icicles - Candidate Sets. Take the time to build a set once, then reuse it quickly many times. Thx – DrewAdams

BTW, I just edited get-icicles.sh, because I think it had some incorrect directories. But I’m no shell script guru. Perhaps you could sanity-check my change? Thx – DrewAdams

Never heard back from you. I’m assuming there is no problem. Moved this to IciclesIssuesClosed. – DrewAdams


Icicles binds f5. However, f5 is reserved for user bindings, not library bindings (see emacs info pages on keybindings for details). Furthermore, it’s difficult to customize this away - you have to customize a whole keybinding block. I’d recommend binding to non-function keys instead. AndrewHyatt

Good catch. Should be fixed now. And I improved ‘icicle-kmacro’.

I don’t understand your comment about customization difficulty, however. It is trivial to change a single key binding. – DrewAdams


Icicle-mode does not work correctly with emacs 23.0.60.3. When using tab-completion on a path, the entire path prefix disappears. Here’s details:

  1. Load up emacs -q, load up icicles
  2. Assuming directory ~/foo/bar
  3. C-x C-f ~/foo/b <TAB>
  4. At this point ~/foo disappears leaving just b, which emacs then interprets as relative to the current directory.

emacs 23 has some changes to minibuffer completion, so I imagine there is a conflict. – AndrewHyatt

I cannot reproduce that with the CVS build I have: GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of 2008-05-04 on LENNART-69DE564

Please always specify your Emacs version and platform (e.g. use Help > About Emacs), and make sure you are using the latest Icicles files. I have no access to a build later than 2008-05-04, for the moment. If you want to help, you could try debugging the problem:

  1. Load the Icicles source files (not byte-compiled files).
  2. Load the source file minibuffer.el in the Emacs lisp directory.
  3. M-x debug-on-entry icicle-find-file (or whatever command you are using)
  4. Step through the debugger to try to see where the problem occurs. Use ‘d’ to enter a given sexp evaluation and ‘c’ to evaluate a sexp without details.

Thx – DrewAdams

I’m using icicles 22.0, which seems to be the latest. My system is linux, ubuntu Dapper distro.

I traced the problem from ‘icicle-prefix-complete-1’s call to ‘icicle-clear-minibuffer’. It appears that clearing the minibuffer no longer completely clears it anymore? Very strange. I can trace more if you need to, maybe this is enough to go on. – AndrewHyatt

Please do trace more. Please describe what happens when ‘icicle-clear-minibuffer’ is called, versus what you expected it to do. All it does is call ‘delete-minibuffer-contents’, but perhaps that is no longer sufficient. I see no difference, however, in the definition of ‘delete-minibuffer-contents’ in my build and the latest CVS minibuffer.el – it just calls ‘delete-field’. (That is about the only part of minibuffer.el that is the same.) I suspect that the problem is not ‘icicle-clear-minibuffer’.

There are several places things could go wrong in the evaluation of ‘icicle-prefix-complete’. When you trace, here are some things to look for:

  • Does (abbreviate-file-name (substitute-in-file-name icicle-current-input)) DTRT? It should return the input with no change: ~/foo/b.
  • When tracing ‘icicle-file-name-prefix-candidates’:
    • What does (read-file-name-internal "b" "~/foo/" t) return? It should return ("bar/"). And (later), (read-file-name-internal "b" "~/foo/" nil) should return "bar/".
    • What does ‘icicle-file-name-prefix-candidates’ return? It should return ("bar/").
  • If everything looks good until this point, what happens in ‘icicle-save-or-restore-input’? It should return something like /home/ahyatt/foo/bar, that is, ~/foo/bar, but with ~ expanded to your home directory.

They are apparently changing minibuffer.el (which is a new file for Emacs 23) willy nilly. As I said, I don’t try to track the Emacs 23 evolution. But if you can determine where the problem is, I’ll try to DTRT. Thx.

BTW, the only way to tell if you have the latest Icicles files is to look at the Update #: in the header (or the date & time). – DrewAdams

I just picked up a Windows binary built on 2008-05-29 (thanks, LennartBorgman), and gave it a try. I can’t reproduce what you see. However, with IcompleteMode turned on, nothing works! They’ve changed something that makes insertions in the minibuffer by Icomplete Plus be considered part of the minibuffer input.

I’ll investigate that a little further, but please try to follow up on your bug report, to see if we can’t figure it out. (If you use icomplete+.el, then first turn off ‘icomplete-mode’, to eliminate that interference.) Thx – DrewAdams

I updated icomplete+.el so it works now with Emacs 23 (until they change it again ;-)). For your bug, I need your debug input. Make sure to pick up the latest libraries before testing. Thx. – DrewAdams

Never heard back from you. Moved this to stale issues page. – DrewAdams

Sorry for the lack of reply. I’ve been looking at this again. Observations:

in icicle-prefix-complete-1, at the point of icicle-abbreviate-or-expand-file-name, things look messed up. No 2nd arg (for the default dir) is given, and the filename passed in is relative (foo, in the example I gave). I traced this to icicle-file-name-input-p, which returns a null, incorrectly, I think. If I set this function to always return true, things work as I would expect. The method relies of some minubuffer-specific variables which may have changed with the new minibuffer changes in emacs 23.

Here’s why it fails: (stringp minibuffer-completion-predicate) returns nil. minibuffer-completion-predicate is in fact nil, and stays nil throughout a series of calls in the completion. – AndrewHyatt

Update: I think I found the commit which broke this: Stefan Monnier, 2008-04-21 @ 17:18:05 “PC-complete-as-file-name, PC-read-file-name-internal”)

this is part of the diff…

--- a/lisp/complete.el
+++ b/lisp/complete.el
@@ -966,7 +966,7 @@ or properties are considered."
                    (+ (point) 2)
                    (point-min)))
           (minibuffer-completion-table 'PC-read-file-name-internal)
-          (minibuffer-completion-predicate "")
+          (minibuffer-completion-predicate nil)
           (PC-not-minibuffer t))

in icicle-file-name-input-p, if I replace the stringp with a null, things work, at least for case. – AndrewHyatt

Thanks for the update, but I’m afraid it is not clear to me at all and I will need more input to be able to help.

  • In reply to my asking about (abbreviate-file-name (substitute-in-file-name icicle-current-input)), you say: “No 2nd arg (for the default dir) is given, and the filename passed in is relative (foo, in the example I gave).” No second arg should be passed, but in the example you gave, the input was ~/foo/bar, not foo. The result of the sexp should be the same as the input, ~/foo/bar, as I said. Is it?
  • You say “I traced this to icicle-file-name-input-p, which returns a null, incorrectly, I think.” If that is ‘nil’, then the sexp (abbreviate-file-name (substitute-in-file-name icicle-current-input)) would not even be evaluated, so I don’t really know which part of the code you are referring to. ‘icicle-file-name-input-p’ should return non-‘nil’. If it does not, that is a problem. But I wonder if you have the latest version of Icicles (which hasn’t changed for some time), because ‘icicle-file-name-input-p’ now simply evaluates ‘minibuffer-completing-file-name’. If that value is ‘nil’, then there should also be a problem with vanilla Emacs.
  • You say “Here’s why it fails: (stringp minibuffer-completion-predicate) returns nil. minibuffer-completion-predicate is in fact nil, and stays nil throughout a series of calls in the completion.” AND “in icicle-file-name-input-p, if I replace the stringp with a null, things work, at least for case.” Again, I wonder if you have the latest Icicles. Where do you see (stringp minibuffer-completion-predicate) in this code? In the past, that was part of the definition of ‘icicle-file-name-input-p’, but that has not been the case for some time now.

I downloaded a new Windows binary, built on 2008-06-29, and retested (on Windows). I still cannot reproduce the problem. I have a directory ~/foo/bar, and I try C-x C-f ~/foo/b (from any directory), and it completes fine, to ~/foo/bar. Perhaps I’m misunderstanding the recipe, or perhaps the bug is only on a non-Windows platform. I suspect from the above, however, that you might simply not have the latest version of Icicles.

If not, please let me know just how debugging proceeds in ‘icicle-prefix-complete-1’– just where the problem arises. There are several calls to ‘icicle-file-name-input-p’. Another thing to try is to debug ‘icicle-unsorted-file-name-apropos-candidates’ to see what happens there. It should return a list of all matching file names. There is still a test for (stringp minibuffer-completion-predicate) there that might need to be removed. If you find by debugging that that is the problem (so that you are sure), try commenting out the condition (not (stringp minibuffer-completion-predicate))## in ‘icicle-unsorted-file-name-apropos-candidates’.

See also the questions I asked previously:

  • When tracing ‘icicle-file-name-prefix-candidates’:
    • What does (read-file-name-internal "b" "~/foo/" t) return? It should return ("bar/"). And (later), (read-file-name-internal "b" "~/foo/" nil) should return "bar/".
    • What does ‘icicle-file-name-prefix-candidates’ return? It should return ("bar/").
  • If everything looks good until this point, what happens in ‘icicle-save-or-restore-input’? It should return something like /home/ahyatt/foo/bar, that is, ~/foo/bar, but with ~ expanded to your home directory.

Sorry for not being able to find and fix this yet, but I will need some more help from you. Thx – DrewAdams

Sorry, you are correct. I do have an old version. I downloaded the new version and it works with emacs 23 out of the box. Sorry for not checking this properly earlier, I was confused by the version number, and did not look at the update # that you mentioned. – AndrewHyatt

Hey, no problem. Thanks for following up. Too often it happens that a bug report peters out with no user followup, so there is no way to know whether or not a bug exists. The graveyard at IciclesIssuesStale is full of such dead-ends. Happily, this is one I can close. – DrewAdams


Icicles and Gnus attachement:

Using No Gnus 5.110011 on Emacs/23.0.60 I have a problem when Icicles is enabled. Attaching a file to a message result in:

 <#part type="text/plain" filename=#("~/test.txt" 0 10 (auto-composed t))
 disposition=attachment description=test>
 <#/part>

The filename=#(”~/test.txt” 0 10 (auto-composed t)) cause an error when I try to send the mail:

 mm-insert-file-contents: Opening input file: no such file or
 directory, /home/dad/#("~/test.txt" 0 10 (auto-composed t))

Regards. – DanielDehennin

Thanks for your report. I won’t be able to take a look at it before this weekend. However, please try to give me a step-by-step recipe to reproduce it, starting with emacs -Q (no InitFile). I don’t use gnus, so if you can try to narrow it down further, that would help. You can also try loading the Icicles source files (not byte-compiled files) and then stepping through the debugger. For example, M-x debug-on-entry icicle-find-file (or whatever command provokes the problem. Finally, keep in mind that Emacs developers are actively changing Emacs 23, and I don’t necessarily try to track such changes. If we can find the problem, then I will try to fix it, but Emacs 23 is a moving target, so it’s not my priority. Thx – DrewAdams

I will definitely need more info, to look into this. You say “when Icicles is enabled” – do you mean Icicle mode? If you turn off Icicle mode (M-x icy-mode) does the problem go away, or does the problem exist just from loading Icicles and stays a problem, even when Icicle mode is turned off? I ask this because AFAIK, Icicles should have nothing to do with inserting a file in gnus as an attachment – Icicles should have an effect only when you perform completion (or if you use some top-level Icicles command).

What is the command you are using when this happens? Are you somehow using completion? If so, which completion keys are you using (‘TAB’, ‘S-TAB’)? Do you get a similar error if you try to just open the same file using ‘C-x C-f’ (‘icicle-find-file’)? Does /home/dad/~/test.txt generally work when finding a file – does it get transformed in the minibuffer to ~/test.txt (that is, does the first part get dimmed)? Does the file ~/test.txt exist?

Try to trace function ‘mm-insert-file-contents’, after loading the source file mm-util.el and the most recent version of the Icicles source files. Let me know all you can find out, so I can begin to look into this. In short, you will need to somehow connect the error message to some of the Icicles code. Otherwise, this is too far afield to be able to guess what is going on. It could be anything from a possible Emacs 23 change in the implementation of ‘insert-file-contents’ to some interaction between the propertized string and file-name completion. I have no idea at this point and no info to go on. Thx – DrewAdams

Never heard back from you. Moved this to stale issues page. – DrewAdams

Sorry for the delay,

I trace mml-attach-file under emacs -Q and see that when icicles is on, the function read-file-name return

#("~/test" 0 6 (auto-composed t))

When icicles is off the same function only return the string “~/test”.

Does it help you ? – DanielDehennin

Both #("~/test" 0 6 (auto-composed t)) and "~/test" are strings. The first just has the text property ‘auto-composed’ with value ‘t’. Icicles does not apply that text property; it must come from something else you are using – perhaps GNUS. When GNUS or mml called ‘read-file-name’, your input to ‘read-file-name’ was apparently that propertized string.

I prefer to let ‘read-file-name’ return whatever string you input, even if it has text properties. That feature could be useful in certain contexts. I introduced doing that for ‘completing-read’, and that has since been added to vanilla Emacs. In the case of ‘completing-read’, it is clearly an advantage. In the case of ‘read-file-name’, I think it could also be useful.

However, I guess I’ll have to bend on this one, at least for now, since there is brain-dead code out there that assumes the string returned has no properties. It seems that GNUS or mml or whatever blindly prints the string out as the XML attribute value, without removing its properties. That is, it uses the wrong Lisp print function when building the code. It is amazing to me that it doesn’t verify the data it plugs into XML, but you can’t argue with the real world. ;-)

I’ve therefore stripped the text properties in ‘read-file-name’. Please try the latest icicles-fn.el to see if it fixes your problem. Let me know.

But IMO it is the GNUS or mml or whatever code that is at fault here. There is no reason to limit a general function such as ‘read-file-name’ to returning a string with no properties. It would be nice if you grumbled on a GNUS mailing list that it shouldn’t assume that ‘read-file-name’ returns a string with no properties – send them the XML snippet. There is really no excuse for code that naively plugs in a string as an XML attribute value without checking it first. The fix is for the GNUS code to use the proper Lisp print function when creating the XML code. Anyway, thanks for your report, and let me know… – DrewAdams

Ok, I understand, that the reason why other part can have properties too when I complete the input with TAB, the problem is obviously from Gnus, I’ll send a bug report to the Gnus staff. Thanks. – DanielDehennin

Thanks for checking. Just to warn you: I will likely revert this fix, since I think Icicles should stay general about this. I will perhaps add a user option or something to let you choose the behavior. But please do report this as a GNUS bug. Thx – DrewAdams

As I warned, I’ve reverted the fix. You can now set the new option ‘icicle-unpropertize-completion-result-flag’ to non-‘nil’ to achieve the same effect. – DrewAdams


I’m having some trouble with apropos completion. When I press S-TAB, shift-tab, I get a message that says: [No prefix completions]. I think that message indicates that apropos completion is not happening, and I don’t get any matches for the examples in the Icicles documentation, for example M-x \bes doesn’t return any matches. So I described the key S-tab and it says:

<tab> (translated from <S-tab>) runs the command icicle-prefix-complete

I tried this in a vanilla emacs started with --no-init, then loaded icicles using “load-library”, then turned on icicles with “icy-mode”. I just updated icicles this last weekend, didn’t make a difference. I looked at ‘minibuffer-local-completion-map’ to see what icicle-apropos-complete is bound to:

 (tab . icicle-prefix-complete)
 (backtab . icicle-apropos-complete)

Are backtab and S-tab the same? The I’m stumped, any help would be appreciated. – DavidBoon

Oops! Sorry about that. I “improved” the default value because [backtab] is now the canonical representation of all of the ‘S-TAB’ variations ([S-tab], [S-iso-lefttab]). But that is not true until Emacs 22. Should be fixed now. Thanks for the report; sorry for the inconvenience. – DrewAdams

Maybe that wasn’t the problem. I just downloaded the latest icicles, and still have the same problem. I asked a friend to describe their “S-TAB” and they get “<backtab> is undefined” I get “TAB (translated from <S-tab>) runs the command indent-for-tab-command,”

I tried this: (define-key minibuffer-local-completion-map [S-tab] 'icicle-apropos-complete)

And that fixes my issue…maybe a hack for now… – DavidBoon

Hmm. What is the value of option ‘icicle-generic-S-tab-keys’? If you use Emacs 20 or 21, then it should be, by default, ([S-tab] [S-iso-lefttab]), which will make [S-tab] DTRT. If you use Emacs 22 or 23, then [backtab] should work (let me know if that is your case and [backtab] doesn’t work). You didn’t identify your Emacs version.

If you use Emacs 20 or 21 and the value is still [backtab], then perhaps you are picking up an old value from your custom-file. If your custom-file has no value for this, then the default value should be ([S-tab] [S-iso-lefttab]), and that should work. If not, let me know the details (Emacs version, value in custom-file, etc.).

BTW, you do not want to just bind [S-tab] to ‘icicle-apropos-complete’ in any case – it should be bound to ‘icicle-generic-S-tab’. That makes it work for both apropos completion and key completion in Emacs 22 or later, and it makes ‘S-TAB’ move backwards among candidates in buffer ‘*Completions*’. IOW, ‘S-TAB’ has multiple uses in Icicles. – DrewAdams

(autoload 'icicle-mode "icicles" "icicle mode." t)
(require 'icicles)
(setq icicle-modal-cycle-up-key "\C-p")
(setq icicle-modal-cycle-down-key "\C-n")
(custom-set-variables  
 '(icicle-control-reminder-prompt nil)
 '(icicle-require-match-flag 'no-match-required) ;;'partial-match-ok)
 '(icicle-buffer-require-match-flag  'no-match-required)
 '(icicle-test-for-remote-files-flag nil)
 '(icicle-download-dir "~/emacs/packages/icicles")
 '(icicle-prompt-suffix ""))
...
(icicle-mode 1)                         ; Turn on Icicle mode.
...

That is what I use to load icicles I’m using emacs version: GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of 2008-02-20 on mymachine

icicle-generic-S-tab-keys is a variable defined in `icicles-opt.el’. Its value is ([backtab]). That doesn’t seem to be working for me, should I reset it to ([S-tab] [S-iso-lefttab]) ? – DavidBoon

What do you get for ‘C-h k’ when you hit ‘S-TAB’ at the top level (not from the minibuffer) in Icicle mode? It should say:

<backtab> (translated from <S-tab>) runs the command
icicle-generic-S-tab, which is an interactive compiled Lisp function.

It is bound to <backtab>.

It sounds like that might not be true in your case.

Next, try using ([S-tab] [S-iso-lefttab]) as the value of ‘icicle-generic-S-tab-keys’.

  • If that doesn’t work, then the problem is not with [backtab]. Let me know, and we’ll dig further.
  • If that works, then something is wrong with [backtab] getting mapped to those keys. That would be an Emacs problem. In that case, you might try upgrading to a more recent CVS snapshot. I’m using an Emacs 23 snapshot from 2008-05-04 on Windows, with no problem. It works for me also with Emacs 22. It also works for me with a January 2008 CVS snapshot (Emacs 23), however.

Rereading your first message, my impression is that [backtab] is bound to the right keys in Icicles, but when you hit ‘S-TAB’ Emacs is not translating that to [backtab]. I’m no expert on those low-level key translations. In this case, I suggest you contact an Emacs mailing list – one of these:

 emacs-devel@gnu.org
 help-gnu-emacs@gnu.org

If that is the case, then there is no relation with Icicles – you can use the workaround of skipping [backtab] and using [S-tab] directly. But you should try to find out why Emacs doesn’t treat ‘S-TAB’ as [backtab] on your machine. Sounds like an Emacs bug.

BTW, you no longer need ‘icicle-control-reminder-prompt’ and ‘icicle-prompt-suffix’ – they no longer exist. – DrewAdams

Thanks Drew! Once again your level of support just rules. Here’s what I did to get around it as you suggested: (custom-set-variables ‘(icicle-generic-S-tab-keys ‘([S-tab] [S-iso-lefttab])))

That works. When I describe S-tab, I get:

<S-tab> runs the command icicle-generic-S-tab, which is an interactive
compiled Lisp function in `icicles-cmd.el'.

It is bound to <S-tab>, <S-iso-lefttab>.

My emacs version is: GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of 2008-02-20 on mymachine Which is pretty recent. I reverted back to this version when the emacs trunk seemed unstable in the last week or so since the font-backend changes where merged in.

With a very recent build(GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of 2008-05-19 on U0103223-XPA), S-tab is translated to backtab correctly:

<backtab> (translated from <S-tab>) runs the command backward-button,
which is an interactive compiled Lisp function in `button.el'.

It is bound to <backtab>, M-TAB.

So this is not really an icicles bug and probably will work fine once I get back to using a recent trunk build. Thanks for helping me out. – DavidBoon

Glad to hear both that you’ve got it working and that it’s not an Icicles bug or a current Emacs bug. Thanks for going the extra mile to check things in a more recent CVS snapshot. – DrewAdams


Regarding the backtab/S-tab/S-iso-tab problem,, I just want to report that it is broken on my system as well: GNU Emacs 22.2.1 (i386-apple-darwin8.11.1, Carbon Version 1.6.0). I wonder if this problem is specific to Emacs 22/Mac OS 10.4?

The suggested fix works for me, but only if it precedes the (icy-mode 1) form:

  (require 'icicles)
  (setq icicle-generic-S-tab-keys '([S-tab] [S-iso-lefttab]))
  (icy-mode 1)

Perhaps that should be mentioned in the ‘icicle-generic-S-tab-keys’ doc string. – KevinRodgers

I think you’re saying that ‘backtab’ is apparently not being translated to ‘S-tab’ and ‘S-iso-lefttab’ on Mac OS 10.4. Is that correct? If so, please file an Emacs bug for that.

I’ve added a note in the doc string, as you suggest, though bugs and workarounds are not usually part of the normal doc (as opposed, e.g., to release notes etc.).

Wrt the code you use: Does it not work for you to customize ‘icicle-generic-S-tab-keys’ (using Customize)? If so, there might be an Icicles bug here. If not, that is the recommended way to go. I prefer not to get into telling people to use code such as you wrote, if Customize does the job correctly.

IIUC, there is no Icicles bug here. Let me know if I misunderstand. Thx – DrewAdams

Yes, in the Mac OS window system Emacs does not see S-tab or S-iso-lefttab. In Emacs -Q `C-h k S-<tab>’ says:

    TAB (translated from <S-tab>) runs the command indent-for-tab-command

I believe you that this is an Emacs bug, but I can’t find any reference to backtab in the Emacs manual, the Emacs Lisp manual, or the NEWS file to support that so I’m not comfortable reporting it.

I appreciate your disdain for polluting the Icicles doc strings with notes like that – perhaps a comment in the source instead would be enough for now.

And I understand your preference for using Customize, but I intend to stick to .emacs 😊

Thanks! – KevinRodgers

I did add a note to the doc string, as I mentioned:

 In Emacs 22 and later, `backtab' is the canonical key that represents
 both `S-tab' and `S-iso-lefttab', so that is used in the default
 value.  If, for some reason, `backtab' is not being translated to
 `S-tab' and `S-iso-lefttab' on your platform, you might want to
 customize the value to ([S-tab] [S-iso-lefttab]).  And if your Emacs
 version is 22 or later, please file an Emacs bug about the lack of
 translation.

Wrt reporting the bug: StefanMonnier stated that ‘backtab’ is now the “canonical” form of Shift + Tab in Emacs, and he said that if it’s not getting properly translated then it’s a bug. I suggested that this be documented and he (and others) agreed. I don’t know if that has been done yet. Here is the thread: http://lists.gnu.org/archive/html/emacs-devel/2008-05/msg00256.html

Does that make you feel any better about reporting it? ;-) It’s better if you are the one to report it, since you see it and can provide any details they might need.

Moved this to IciclesIssuesClosed. Thx – DrewAdams


Icicles tab-completion does not work with current emacs 23 from cvs. this

 Find file: ~/src/

becomes after pressing tab

 File or directory: src

HannesJanetzek

I assume you mean File or directory: as the prompt in both cases (not Find file: in the first case), right? If not, then you need to explain what command you used – ‘icicle-find-file’ should use the same prompt always.

I cannot test Emacs 23 on UNIX or GNU/Linux, and I don’t see the equivalent on Windows. I tried with a January build of Emacs 23 on Windows, and it behaves normally.

After pressing ‘TAB’ the minibuffer should stay the same – in your case that would be File or directory: ~/src/ – but the contents of that directory should be shown as candidates in ‘*Completions*’. That is what I see on Windows and also what I see with Emacs 22 on GNU/Linux.

To go further with this, you’ll need to provide some more information. Start with emacs -Q (no .emacs); then load only the Icicles source files (not the byte-compiled files); then M-x debug-on-entry icicle-find-file; then ‘C-x C-f’ and step through the debugger.

Keep in mind that CVS Emacs is a development version and is not necessarily supported by Icicles. There are currently lots of Emacs bugs in that version, and they are playing with some of the C-language completion code as we speak. Dunno if that’s related. Dunno if what you’re seeing is an Icicles problem or an Emacs problem. Can you try with Emacs 22, 21, or 20? If not, please try using the debugger to provide some more info.

You can also report the info by email via M-x icicle-send-bug-reportDrewAdams

Actually, I suspect that this is an Emacs bug introduced in the last day or two. See the thread “a bug rendering ido unusable” in emacs-devel@gnu.org[2]. This seems to be the conclusion:

“It turns out the problem is in file-name-all-completions: for some reason, it fails to add the expected trailing / on directories.” – StefanMonnier

So please test also with Icicle mode turned off to see if you get the same problem. Thx – DrewAdams

Stefan says that Emacs bug should be fixed now in CVS. Please let me know if this is really what you ran into or if the problem still exists. – DrewAdams

I wasnt sure if this is an emacs bug or if Icicles is not up to date with recent changes of Emacs. Probably it’s a bug in Emacs. Yes, I mean icicles-find-file and the icicles version bzr rev 128 worked until now. The debugging method you mention above didnt showed anything after pressing tab. I started to track down where the bug was introduced. But it needs a bootstrap each time I try, so this might take a while. the checkout from 04-09 23:25 is the last working version i’ve found. so somewhere between then and 04-23 7:15 the bug appeared.. The todays version does not work. --HannesJanetzek

Ok, I found the commit causing the trouble. it is “(Qdefault_directory): New variable.” from 2008-04-21 23:26:00. Drew could you have a look this? I guess Icicles makes an assumption of what should be returned which doesnt hold anymore. – HannesJanetzek

I don’t update Icicles wrt CVS changes – that’s what I was saying above. If someone identifies a problem and I can see how the Emacs 23 Lisp code changed to provoke the problem, then I generally update Icicles to accommodate the change. But I am not trying to keep Icicles up-to-date wrt Emacs CVS as it evolves. Later, when it becomes more stable, I will attempt that. There are far too many Emacs bugs now and the code changes too often.

AFAIK, Icicles makes no assumptions beyond the signatures of the standard Lisp functions and the behavior of the standard variables, such as ‘default-directory’. If those change, then sometimes I need to update Icicles. If you can determine any such Lisp interface changes, let me know, and I’ll try to take them into account.

Please try without Icicles, to see if you still see the problem. Then try with Icicles but with Icicle mode turned off, in case just loading Icicles provokes the problem. Then, please step through the debugger, letting me know what you see.

I don’t know what you mean by “debugging method you mention above didnt showed anything after pressing tab”. If the error is raised during execution of ‘icicle-find-file’, then stepping through that function should show where things go wrong. You can also try setting ‘debug-on-error’ to ‘t’ and see what that backtrace shows. (Always use only source files, not byte-compiled files, for debugging.)

If this is an Emacs bug, and it was not fixed by Stefan’s fix, then it should be reported using M-x report-emacs-bug. You will need to give a narrow recipe, starting with emacs -Q. Either way, Icicles bug or Emacs bug, it needs to be narrowed down some in order to tackle it. – DrewAdams

FYI - Dunno if it affects this bug, but I just fixed another bug introduced by an Emacs 23 change (which allows a list of default values for minibuffer read functions). You might give the latest icicles-fn.el a try. – DrewAdams

I made a change that seems to fix it, at least on Windows. Please try the latest and let me know. Thx - DrewAdams

Your latest changes fixed this Issue. Thank You! – HannesJanetzek


When trying to visit a file, Emacs hangs without showing a prompt and finally returns back with the following message: condition-case: Variable binding depth exceeds max-specpdl-size This happens even if I use find-file-literally, which shouldn’t care about Icicles at all, AFAIK; and even if icicle-mode is deactivated (after being activated at start-up).

The really weird thing: this only seems to happen if Icicles is loaded during start-up. If I do

 (require 'icicles)
 (icicle-mode t)

after start-up, there is a slight pause before the prompt shows, but it does show. Is there any reason this should matter? --AlexeyRomanov

This is an important bug, obviously. Please help by getting some more info for me. I don’t want to scare you off by the long request that follows – any information at all that you can provide will help. But the more you can tell me, the more I can help.

I assume you are using the latest Icicles files (if not, please do). What is your platform/OS?

What I really need is a step-by-step recipe to reproduce the problem, starting with emacs -Q (that is, no .emacs). First, however, get rid of any byte-compiled Icicles libraries, so you load only the Lisp source files.

Do not use your .emacs file for testing, in particular. Do not use any other libraries except Icicles. Definitely, do not use anything that restores state from some previous Emacs invocation. (It is possible that you have out-of-date info saved in a desktop file or your ‘custom-file’Icicles info, for example. You must not let Emacs see this.)

What does evaluating this give in your Emacs version immediately after emacs -Q (i.e. without loading Icicles): (boundp 'read-file-name-function)? What does evaluating this give: (symbol-function 'read-file-name)?

For Emacs 22 and later, Icicles now takes advantage of variable ‘read-file-name-function’, instead of redefining ‘read-file-name’. This change is no doubt at the heart of the problem you see, but I don’t know what the problem is. If you know EmacsLisp a little, you can check the values of some variables and use the debugger a bit to see what is going on.

If you have Emacs 22 or 23, this is what should happen when you enter Icicle mode:

  • ‘icicle-old-read-file-name-function’ gets set to the value of ‘read-file-name-function’.
  • ‘read-file-name-function’ gets set to ‘icicle-read-file-name’.

When you exit Icicle mode:

  • ‘icicle-old-read-file-name-function’ gets set to the value of ‘read-file-name-function’.
  • ‘read-file-name-function’ gets set to the value of ‘icicle-old-read-file-name-function’ .

‘read-file-name’ does its work by calling the value of ‘read-file-name-function’. In Icicle mode, this is ‘icicle-read-file-name’. When not in Icicle mode, this is whatever it was when you loaded Icicles. In emacs -Q, this will be ‘nil’. If you have loaded some other library before Icicles, and that library sets ‘read-file-name’, then that value is restored when you quit Icicle mode.

When ‘icicle-read-file-name’ is called, it binds ‘read-file-name-function’ to ‘nil’ and then calls the value of ‘icicle-old-read-file-name-fn’ (or ‘read-file-name’, if ‘nil’). This means that it calls whatever the value of ‘read-file-name-function’ was before entering Icicle mode. That means that Icicles can now do its read-file thing on top of whatever other libraries might do to read files.

So please check the values of those variables: after loading Icicles and with Icicle mode and without it. Check twice, to see if exiting is the same as never having entered etc. You can also check (symbol-function 'read-file-name) with Icicle mode and without it.

If you can, please also try M-x debug-on-entry icicle-read-file-name, and then use ‘C-x C-f’ and step through the debugger using ‘c’ and ‘d’. (Make sure you don’t use byte-compiled files.) Follow along looking at the source code while you do this, and let me know what you see. You can send me parts of the debugger backtrace that you think are helpful.

My suspicion and my hope is that the problem will go away with emacs -Q. I suspect that there is something in your InitFile or ‘custom-file’ or some other saved file that is restoring out-of-date state from a past version of Icicles.

Please let me know everything you can. Use M-x icicle-send-bug-report to send me the info by email, if you can. That will be easier than communicating here.

Thanks very much for your help, Alexey. Sorry for the inconvenience. – DrewAdams

I’ve updated the files with, hopefully, a fix. Please let me know if it helps. – DrewAdams


`icicle-find-file` does not show *.map files as completion candidates. Reproduced as follows:

  1. Create more than two files with same name but different extensions including map as one of them: for example, hello.map, hello.c…
  2. Run `runemacs -Q`
  3. Evaluate `(require ‘icicles)
  4. Evaluate `(icy-mode)`
  5. Invoke `icicle-find-file`, type hello and press tab. You will see hello.c is Sole prefix completion while there is hello.map too.

This has nothing to do with Icicles, I believe. Please check the value and meaning of ‘completion-ignored-extensions’. – DrewAdams


Hi, I’m having an issue with completion of files in ‘default-directory’, I’m using C-x C-f(icicle-find-file). When I’m in the minibuffer, and I’m editing the default file path, for example deleting directories or even just typing. I suspect that the text I’m typing may be getting interpreted as remote paths. See the ‘NET USE’ below. I first noticed this when my shell-file-name was set to “bash.exe”, I was noticing pretty slow response, so I nil’d that, and I also have the same behavior with cmdproxy. I started emacs with “runemacs --no-init” then I manually evaluated the loading of icicles all by itself in order to isolate the behavior. This is output from procmon from sysinternals, which shows emacs trying to map my f: drive, which is local. I do notice however, when editing the minibuffer when it includes a path like ~/somepath/somedir this problem doesn’t happen. Only seems to occur when I’m editing something that includes a colon in the path…

1547230	9:52:44.6905121 PM	emacs.exe	5060	RegOpenKey
 HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution 
 Options\cmdproxy.exe NAME NOT FOUND	Desired Access: Read
1547231	9:52:44.6910292 PM	emacs.exe	5060	IRP_MJ_CREATE
 F:\devtools\emacs-23.0.60.1\bin\cmdproxy.exe.Manifest
 NAME NOT FOUND	Desired Access: Generic Read/Execute, Disposition: Open,
 Options: Synchronous IO Non-Alert, Non-Directory File,
 Attributes: n/a, ShareMode: Read, AllocationSize: n/a
1547233	9:52:44.6918830 PM	emacs.exe	5060	FASTIO_NETWORK_QUERY_OPEN
 C:\Documents and Settings\u0103223\emacs
 SUCCESS	CreationTime: 11/12/2007 1:30:24 PM, LastAccessTime: 3/28/2008 9:52:43 PM,
 LastWriteTime: 3/28/2008 9:34:05 PM, ChangeTime: 3/28/2008 9:34:05 PM, AllocationSize: 0,
 EndOfFile: 0, FileAttributes: DA
1547234	9:52:44.6921715 PM	emacs.exe	5060	Process Create
 f:\devtools\emacs-23.0.60.1\bin\cmdproxy.exe	SUCCESS	PID: 1336,
 Command line: f:\devtools\emacs-23.0.60.1\bin\cmdproxy.exe -c "NET USE f:"
1547237	9:52:44.6925870 PM	emacs.exe	5060	IRP_MJ_CLEANUP
 F:\devtools\emacs-23.0.60.1\bin\cmdproxy.exe	SUCCESS	
1547238	9:52:44.6926263 PM	emacs.exe	5060	IRP_MJ_CLOSE
 F:\devtools\emacs-23.0.60.1\bin\cmdproxy.exe	SUCCESS	

And by the way, I’m really loving icicles lately, I must fix this ;-) TIA – DavidBoon

Update: I did a little digging and it looks like the tramp file handler wants to handle this path:

file-name-handler-alist
(("\\.Z\\(~\\|\\.~[0-9]+~\\)?\\'\\|\\.bz2\\(~\\|\\.~[0-9]+~\\)?\\'\\|\\.tbz\\'
  \\|\\.\\(?:tgz\\|svgz\\|sifz\\)\\(~\\|\\.~[0-9]+~\\)?\\'
  \\|\\.g?z\\(~\\|\\.~[0-9]+~\\)?\\'\\|\\.dz\\'" . jka-compr-handler)
 ("^\\([a-zA-Z]:\\)?/$\\|^\\([a-zA-Z]:\\)?/[^/:][^/]*$" .
  tramp-completion-file-name-handler)
 ("^/cygdrive/[A-Za-z]/" . cygwin-mount-map-drive-hook-function)
 ("^//[A-Za-z]/" . cygwin-mount-map-drive-hook-function)
 ("^/[^:@]*$\\|^/|/[^/:]+\\(\\'\\|/\\)" . cygwin-mount-name-hook-function)
 ("\\`/[^/:]+:" . tramp-file-name-handler)
 ("\\`/:" . file-name-non-special))


(find-file-name-handler "f:/somepath" nil)
tramp-completion-file-name-handler

Thanks for the report, David. I will need your help if I’m to figure this out.

It might depend on what Tramp version you have. I don’t really master all that Tramp does in terms of trying to handle remote files. I spent a lot of time with Michael Albinus trying to work something out, so Tramp could be kept at bay. Supposedly, he has taken care of things in the Tramp code, but I don’t know what Tramp version he fixed this in. You might try uncommenting the binding of ‘tramp-completion-mode’ in ‘icicle-call-then-update-Completions’ (and add a right paren at the function end) to see if that helps with your version of Tramp.

Icicles tries to test for a remote file, including a mapped network drive, and it then avoids going to tramp for a remote file name. The function ‘icicle-file-remote-p’ tries to take care of this. On Windows, it calls NET USE to test whether a drive is local or a mapped network drive. This code works for me, with both bash (which is what I use, with Cygwin) and with cmdproxy. It is hard for me to determine what might be going wrong in your context.

I did have another user report a similar problem, but the problem was apparently with his system’s network settings or something, and it magically got fixed (!). One thing to try would be to see what happens if you issue a NET USE call outside Emacs, to simulate what Icicles does. If you are comfortable with Windows commands and if you can read the EmacsLisp code for ‘icicle-file-remote-p’, then you can try to see what the problem is. The NET USE call should not take long at all – that’s the reason I call it: to avoid accessing a network drive. It should return 0 for a mapped network drive but not for a local drive.

If you don’t make progress finding the problem, then there are some things you can do to prevent Icicles from trying so hard. See Icicles - Icompletion, in particular, Icicles - Icompletion#toc4. There are two places where Icicles calls ‘icicle-remote-file-p’: (1) for incremental completion and (2) for highlighting non-matching input. For #1, you can turn off incremental completion at any time via `C-#’, which toggles option ‘icicle-incremental-completion-flag’. For #2, you can customize options ‘icicle-highlight-input-completion-failure’, ‘icicle-highlight-input-completion-failure-delay’, and ‘icicle-highlight-input-completion-failure-threshold’.

It’s a shame to give up either of these features, but if you must, you must. I would like to fix the problem, whatever it is, but I will need more info, since I can’t reproduce it here. If you have the time, you might share your findings with Michael Albinus (the Tramp maintainer), if Tramp is implicated, as I suspect.

One thing you might try first is M-x debug-on-entry icicle-file-remote-p (after loading icicles-fn.el, not icicles-fn.elc). Then step through the debugger. For a local drive (e.g. c:), I get ‘nil’ for all three ‘or’ branches. Perhaps the last branch, which uses ‘file-remote-p’, is giving you non-‘nil’? Perhaps I can skip the second and third branches if the file name matches a Windows drive letter (since the first branch already takes care of that)?

IOW, perhaps this would be better. I’m not sure if it is sufficient, but you might want to experiment with it:

  (defun icicle-file-remote-p (file)
   (if (and (eq system-type 'windows-nt)
             (let ((case-fold-search t))
               (string-match "\\`\\([a-z]:\\)" file)))
        (eq 0 (condition-case nil
                  (call-process shell-file-name nil nil nil
                                shell-command-switch
                                (concat "NET USE " (match-string 1 file)))
                (error nil)))
      (or (and (fboundp 'ffap-file-remote-p) (ffap-file-remote-p file))
          (and (fboundp 'file-remote-p) (file-remote-p file)))))

Please let me know what you try and what you find out. Sorry for the inconvenience. – DrewAdams

I changed the definition of ‘icicle-file-remote-p’ to that shown above. Let me know if that helps. To try it, just eval that definition (and then toggle ‘icy-mode’ twice). Otherwise, you will need to download all of the Icicles files, because I updated all of them this morning. – DrewAdams

I tried the new definition of ‘icicle-file-remote-p’, It seems to help a little. Typing in the minbuffer is a little more responsive. But, still noticably slow. When I remove, by commenting out, the section that invokes the ‘net use’, responsiveness in the minibuffer is excellent. So I think it’s definately the ‘net use’. The one thing that seems odd is that ‘net use’ is invoked a lot, for just about every character I type.

See ‘icicle-Completions-display-min-input-chars’ and the other variables I mentioned, for tuning (Icicles - Icompletion#toc4). If you don’t, yes, it is tested for each edit, to detect whether the input is a non-match. That’s the point. And that’s why there are options to not do that in specific (or all) contexts. You should be able to find satisfactory behavior with those options. If not, let me know what the problem is. – DrewAdams


For some reason ‘S-TAB’ works as key completion even in minibuffer for me. It is bound to ‘icicle-generic-S-tab’ (checked with ‘C-h k’). Icicle-apropos-complete works properly when called by M-x or from Minibuf menu.

I use the latest patched EmacsW32.

Icicles prompt shows <S-iso-lefttab> instead of <S-tab>, and I am not sure what key “iso” is supposed to mean. – AlexeyRomanov

It means that your keyboard’s ‘S-TAB’ key is actually <S-iso-lefttab>, not <S-tab>. Icicles takes care of both types of keyboard. – DrewAdams

The same happens for me when i switch on CuaMode. I’ve tried to track this down and ended up in the icicle-completing-p function. The expression:

      (where-is-internal 'icicle-candidate-action nil 'first-only)

returns nil when cua-mod is enabled (without CUA mode, it evaluates to something != nil and everything is fine). – KaiTetzlaff

So is there a way to deal with this (without leaving CuaMode)? – AlexeyRomanov

FYI –

1. A minor mode keymap (such as ‘cua-global-keymap’) overrides all local keymaps (such as ‘minibuffer-local-completion-map’).

2. CuaMode apparently binds ‘C-RET’ to ‘cua-set-rectangle-mark’ in the minor-mode keymap ‘cua-global-keymap’.

3. Icicles, in order to determine whether completion is in effect, tests whether ‘icicle-candidate-action’ is bound. It is bound to ‘C-RET’ normally, but CUA mode’s minor-mode binding overrides that.

4. Other tests for completing are more expensive. Nevertheless, I’ve changed it now, so that it should work in this case. Please try the latest version.

5. However, I cannot recommend that you use CUA mode with Icicles. It’s untested. Unlike Icicles, which binds mainly minibuffer keys, CUA mode binds tons of keys at the top (minor-mode) level, and these will all override the minibuffer key bindings, which are local. So you’re on your own if you try to use CUA mode at the same time as Icicles.

6. I expect that you will need to bind one or more keys differently, to accommodate both CUA mode and Icicles. At a minimum, you will need to either (a) bind ‘cua-set-rectangle-mark’ to something besides ‘C-RET’ in CUA mode or (b) bind ‘icicle-candidate-action’ to something besides ‘C-RET’ in each of the minibuffer completion maps when you are in Icicle mode.

7. More generally, I recommend that you wean yourself from CUA mode. I go back and forth all the time between Emacs, with its normal, non-CUA bindings, and MS Windows apps, with their CUA bindings, such as ‘C-v’. If I can do it, so can you. It might take some getting used to, but it is well worth it, IMO. Do as you like, of course – just a word to the wise. – DrewAdams

Drew Adams helped me to find a solution how to handle ‘C-RET’ using CUA mode and Icicles.

1. Define a function ‘my-c-return’.

(defun my-c-return ()
  "When in minibuffer use `icicle-candidate-action', otherwise use `cua-set-rectangle-mark'."
  (interactive)
  (if (window-minibuffer-p (selected-window))
      (call-interactively 'icicle-candidate-action)
    (call-interactively 'cua-set-rectangle-mark)))

2. Then ‘M-x customize-option icicle-top-level-key-bindings’:

  • Click an ‘INS’ button (anywhere) to add a new entry.
  • In the ‘Value Menu’ for the new entry, choose ‘Command to remap’ and enter this command name in place of ‘ignore’: cua-set-rectangle-mark.
  • In the field ‘Command’ for the entry replace ‘ignore’ by my-c-return. This will remap the CUA command to the command defined above, which will do the Icicles thing in the minibuffer and otherwise do the CUA thing.
  • Set the field ‘Command’ to t.
  • Click the ‘State’ button near the bottom of the buffer and choose ‘Set for Current Session’ (to try it) or ‘Save for Future Sessions’ (if you want to keep it, after testing).

3. ‘M-x icy-mode’ twice to toggle Icicle mode off and on again. – DirkJoos


Filename completion seems to be broken for me. I have a directory F:\MyProgramming. When I try to use ‘icicle-find-file’ and enter F:\MyProg <tab> it doesn’t find any prefix completions; If I enter F:/MyProg <tab> it completes to MyProgramming\, losing F:. – AlexeyRomanov

As I said, in this case it completed to MyProgramming/ (not \, as I wrote above), which is interpreted as a subdirectory of the current directory. This turned out to be because insert-default-directory was nil. I changed it back to t and it works correctly now. – AlexeyRomanov

No, it’s not about ‘insert-default-directory’. The reason changing that back to ‘t’ helped is that the directory that is then inserted uses ‘/’, not `\’. In Icicles, always use ‘/’ as the directory separator – always. Then, you will have no problem, with or without ‘insert-default-directory’. – DrewAdams


I am using emacs 21.3.1 on RHEL 3

I have been using icicles for a while, but only using basic functions like S-TAB. I recently decided to try the progressive completion feature, but have not been able to get it to work. I updated icicles today 2007-Feb-28 (in case the problem had been fixed, but alas it is still not working for me). To do the update, I use the ‘M-x icicles-download-wizard’. I then byte compile when prompted. Finally I exit emacs and restart emacs to test the new version of icicles. BTW, is there a way to print the icicles version?

When I try to follow the example on the progressive completion page, Step one works fine. ‘C-h f char S-TAB’ produces a list of functions containing “char” However when I try the next step ‘M-*’ produces the following message: “No previous locations for find-tag invocation”. Not sure what is wrong.

Pressing ‘C-h k’ and then pressing ‘M-*’ produces “M-* runs the command icicle-pop-tag-mark” (I even tried this while in the mini-buffer after using S-TAB to see if it the key was rebound in the minibuffer, but apparently not).

Not sure if that is the problem, that the key is not being rebound in the minibuffer in my case. – IanPerryman

Thanks for your report. What version of Emacs are you using?

Icicles has no version number per se. Instead, each Icicles library has an `Update #’ in the file header, which is updated automatically at each save.

I suspect that something in your InitFile is interfering somehow. Please try again, starting from emacs -Q (or emacs -q --no-site-file), to bypass your init file. If the problem goes away, then we can check what’s happening in your init file.

It is fine that the global key binding of ‘M-*’ be ‘icicle-pop-tag-mark’. The global binding should be irrelevant here, because ‘M-*’ should have a local binding in the minibuffer completion keymaps.

To check the minibuffer binding, load library help-fns+.el (or help+20.el if you use a version of Emacs prior to 22). Then use ‘C-h M-k’ and enter one of the minibuffer completion keymap names – e.g. ‘minibuffer-local-completion-map’. You should see this binding of ‘M-*’ in the list:

 M-*             icicle-narrow-candidates

If you don’t want to load the help-enhancement library, then just use ‘C-h v minibuffer-local-completion-map’, but in that case you will need to look for (27 keymap ... (42 . icicle-narrow-candidates)...):

  ...
  (27 keymap
     (25 . icicle-yank-secondary)
     (58 . icicle-pp-eval-expression)
     (67108902 . icicle-save-predicate-to-variable)
     (38 . icicle-narrow-candidates-with-predicate)
     (42 . icicle-narrow-candidates)
     ...

I expect, from your description, that you won’t find ‘M-*’ bound to ‘icicle-narrow-candidates’ in this minibuffer keymap, and that is the problem. But I expect that there is something in your init file that is causing this.

Let me know what you find out. Thx – DrewAdams

Thanks for the reply Drew

I am using emacs 21.3.1 on RHEL in a X-Windows environment (Gnome) … you may have missed it at the top of the original post. I get the same problem with “emacs -q --no-site-file”

When I loaded the help+20.el file and dumped the key bindings for minibuffer-local-completion-map, I get about 444 lines of stuff … too much to post here. However, of note there are many bindings that look like C-<char> bound to various icicle funcitons but only few M-<char> and all of these are in <> like this:

<M-S-delete> icicle-erase-minibuffer

Then there are lots of ESC <char> type bindings including:

ESC * icicle-narrow-candidates

However when I press that sequence (literally using the escape key and the *) I get the same behaviour as when I use the Alt key (which is my Meta key). It is the same for both Alt-L and Alt-R if that matters. In any case I get the same “No previous locations for find-tag invocation”.

(BTW, this was working previously since I made a post several months ago when I first started using icicles.) – IanPerryman

Should be fixed now. Thanks for your help.

FYI, the problem was that ‘pop-to-mark’ is bound starting with Emacs 21 to ‘M-*’ (it doesn’t exist in Emacs 20). And command remapping isn’t available until Emacs 22. So, for Emacs 20 and 21, I use ‘substitute-key-definition’, instead of remapping. Well, since a minor-mode keymap takes precedence over even a local keymap such as minibuffer bindings, the ‘M-*’ binding in ‘icicle-mode’, namely ‘icicle-pop-tag-mark’, was taking precedence over ‘icicle-narrow-candidates’. The same problem exists for `M-.’, but I had already taken care of that. Please try the latest icicles-mode.el. Thx – DrewAdams

Ah that got it fixed. Thanks for the details and the quick repair. BTW, I really like icicles! Thanks for the great package. Ian


I’m getting similar results to dsl5402B33F.pool.t-online.hu at IciclesDiscussion, only I’m not in ClearCase – just roaming local and networked drives.

I was using an old version of Icicles (Last-Updated: Wed Mar 14 16:48:05 2007 (-25200 Pacific Daylight Time) Update #: 20754) and it worked fine. I just updated to the latest (Last-Updated: Sun Jan 13 13:56:00 2008 (-28800 Pacific Standard Time)Update #: 22004) and that is when the slowness started.

If I do a C-x C-f, it can take 2-3 seconds before the prompt appears. When I type in a directory, it can take up to 8 seconds before the cursor comes backup.

I tried what the user did above: (setq icicle-incremental-completion-threshold 0)

(setq icicle-incremental-completion-delay 1)

And that did nothing to my slowness. Again, it works fine with the older version and I’m not sure what changed. – MikeHostetler

Sorry to hear that. I can think of a couple of possibilities you might check.

You can test whether the slowness is due to incremental completion, by toggling that off (`C-#’ in the minibuffer).

What is the value of option ‘icicle-highlight-input-completion-failure-flag’? If it is ‘t’, try setting it to ‘nil’ to see if that helps. Toggling incremental completion off also turns this option off, so if `C-#’ solves the problem, then you might try just setting ‘icicle-highlight-input-completion-failure-flag’ to ‘nil’ instead of turning off incremental completion.

I notice that with this (very useful) option turned on in Emacs 22 inputting characters is noticeably slower. I don’t know why this would be true only for Emacs 22 (not Emacs 20).

If the slowdown is mainly annoying in some contexts (e.g. file-name completion), and you want to keep the benefit of input non-match highlighting most of the time, then you might want to use `C-#’ in those problematic contexts. If the problem is in fact mainly for file-name completion, thenaAnother solution is to set the option to ‘strict-only’ – the highlighting will then appear only for strict completion. (File-name completion is usually lax, not strict.)

What is the value of option ‘icicle-add-proxy-candidates-flag’? It should be nil. (You can toggle it in the minibuffer using `C-M-_’.)

Other than that, I have no clue. Let me know what you find wrt these suggestions. – DrewAdams

Setting icicle-highlight-input-completion-failure-flag to nil did the trick. It’s still slower than before, but not annoyingly so. `C-#’ did make it faster yet but I like incremental completion, so I turned it back on and turned off ‘icicle-highlight-input-completion-failure-flag’ and it’s very usable now.

‘icicle-add-proxy-candidates-flag’ was nil the whole time.

From your explanation, I did fail to understand what to set to ‘strict-only’. Yes, this does seem to only happen with filename completion – command completion is very snappy.

I failed to say what I was running – NTmacs 22, which bills itself as: `GNU Emacs 22.1.50.1 (i386-mingw-nt5.1.2600’

Thanks for your help – and a great package! – MikeHostetler

Glad to see you solved it. Dunno why file-name completion is slow on Emacs 22. What I meant about ‘strict-only’ is that you can customize ‘icicle-highlight-input-completion-failure-flag’ to ‘strict-only’, since file-name completion is (usually) lax. In Customize, the value is listed in the Value menu as Only during strict completion. The actual value this gives is ‘strict-only’.

I will see if I can tell why Emacs 22 has a problem with file-name completion. Perhaps I will also set the default value to ‘strict-only’, but that seems a shame. Thanks for the report. – DrewAdams

Okay, I tried setting ‘icicle-highlight-input-completion-failure-flag’ to ‘strict-only’ and that sped things up, but still annoying. I went back to to setting it to nil and it’s much better

FWIW – Part of this may be that I spend as much time on network drives as I do local ones. With ‘strict-only’ the local drives are much snappier than the network. Still, there was no difference when using Icicles from a year ago – even with Emacs 22. – MikeHostetler

That’s interesting. That shouldn’t happen. If you are completing a remote file name, then there should be no attempt to highlight the non-matching input. I would like to find and fix this bug.

Would you please test this for me? You can correspond by email; that would be easier: you can use ‘M-x icicle-send-bug-report’ to get the email address.

Warning: The test will be a pain (but it will be short), because ‘icicle-highlight-input-noncompletion’ is called each time you type a character. If you need to turn it off, the quickest way is M-: (cancel-debug-on-entry). That will bypass input updating – it will take you forever to do ‘M-x cancel-debug-on-entry’.

To test:

1. Load the source code (not the byte-compiled code) of at least icicles-fn.el.

2. Toggle twice: ‘M-x icy-mode’ ‘M-x icy-mode’ to refresh to the source definition.

3. Set ‘icicle-highlight-input-completion-failure-flag’ to non-‘nil’.

4. ‘M-x debug-on-entry icicle-highlight-input-noncompletion RET’.

5. Try to type a remote file name using, e.g., ‘C-x C-f’, or whatever you were doing that manifested the problem.

What should happen is that the first branch of the ‘cond’ is taken, because (icicle-file-name-input-p), (fboundp 'file-remote-p), and (file-remote-p input) should each return non-‘nil’. It seems, however, that one of them is returning ‘nil’ in your case. I want to learn why. If it is the first, then please descend into ‘icicle-file-name-input-p’ to see if you can tell why.

Question: Are you using Tramp? If so, which version? I had a lot of trouble with this, and Michael Albinus, the Tramp maintainer, fixed a few Tramp problems in this regard, but perhaps you have an older version or perhaps there are still some problems there. If Tramp is the problem, could you perhaps try using FTP as the Tramp method, to see if that bypasses the problem (just for a test). Also, you might try uncommenting the ‘let’ binding of ‘tramp-completion-mode’ in ‘icicle-call-then-update-Completions’ (and add another `)’ at the end).

This is an important bug. I realize that you already have a workaround, but I would really like to find out what is happening here. Sorry for all the trouble. Again, feel free to email me. Thx – DrewAdams

I’ve rewritten the code that highlights input mismatches. I improved the performance and I provided finer tuning in the option ‘icicle-highlight-input-completion-failure’ (and removed the suffix ‘-flag’ from its name). In particular, you can now choose to never try to highlight mismatches in remote file names, or to do that only on demand (‘TAB’ or ‘S-TAB’).

I also added treatment of Windows mapped network drives as remote files. There is nothing we can do about the time needed to access remote files, but now you can avoid input highlighting for them without turning off the highlighting for local file names.

The highlighting code itself is snappier now, especially when the mismatch portion which gets highlighted is large - such as what happens when you yank a lot of mismatching text into the minibuffer or you delete a character that is far from the end. I use a binary search now, instead of proceeding a character at a time from the end. Please try the latest version. – DrewAdams


Today I installed icicles with get_icicles.sh script. After running emacs with emacs -q -l .emacs_test, where .emacs_test file is: (setq load-path (append (list “~/elisp/icicles) load-path)) (require ‘icicles) (icy-mode 1) I get strange results. Namely, typing “C-h f char S-TAB” gives no completion, while typing “C-h f delete S-TAB” gives completion list where there are functions containing “char” substring. Any idea what’s wrong? – SewerynKokot

Thanks, this was a bad bug. I introduced it recently while fixing another bug. Should be fixed now – please try the latest icicles-fn.el. – DrewAdams


When using icicles together with AUCTeX I can’t get TeX-command-master (bound to C-c C-c) to work correctly. This is something recent because in the past I’ve successfully used AUCTeX and icicles without problems. I’m using Emacs 22 and all my icicles files are up to date.

I tried deactivating icicles while working on LaTeX-mode but this doesn’t seem to help either; I must completely avoid loading icicles for TeX-command-master to work as expected.

This is the backtrace:

Debugger entered--Lisp error: (wrong-number-of-arguments (lambda nil "Act on a file.
You are prompted for the file and the action.
This is `icicle-object-action' with type `file'."
 (interactive) (icicle-object-action (quote file))) 2)
  file(t t)
  apply(file (t t))
  TeX-command-expand("%`%l%(mode)%' %t" TeX-master-file)
  TeX-command("LaTeX" TeX-master-file nil)
  TeX-command-master(nil)
  call-interactively(TeX-command-master)

– jcc

Sorry about that. I mistakenly uploaded some work in progress. Please try the latest icicles-cmd.el. – DrewAdams

Evreything is working again. Thanks for your help! – jcc

Hi Drew,

This error has appeared again. Can you tell what you changed last time so I don’t bother you every time this comes up?.

The stack trace is identical to the one I reported previously but the initial message is a little different now:

Debugger entered--Lisp error: (wrong-number-of-arguments (lambda nil "Act on a file.
You are prompted for the file and the action.
During file-name completion, you can delete the file named by the
current candidate, using `S-delete'.

— jcc

Hi Jcc. Sorry, but this is a known AUCTeX bug. See the bug explanation and workaround here: AUCTex Bug. The bug is currently under discussion in the AUCTeX development group – see the link to the discussion thread at AUCTex Bug. – DrewAdams


Icicles is really nice, but found one quirk that may be a bug. I am using icicles on a Linux system (RHEL3) emacs 21.3.1. Say I start emacs in my home directory and I want to open a file that happens to be in a sub directory (say “sub”), but there are lots of files in that directory with similar names, but the one I want is the only one with “foo” in it.

I hit ‘C-x’ ‘C-f’ s u b ‘S-TAB’ ‘M-*’ f o o ‘S-TAB’ RET

This opens an empty buffer in my home directory with the name of the file from the sub directory. How do I get the relative path (i.e. sub) of the file to be included in what gets returned to find-file so that the correct file is opened. – rtp-isp-nat1.cisco.com

What you describe works for me. I probably need some more info, such as what happens when you hit ‘S-TAB’ the first time – e.g., whether there are other completions for ‘sub’ besides ‘sub’ itself. Please describe your directory structure and the files/directories whose names match ‘sub’ and ‘foo’.

If there is only one completion for ‘sub’, then when you hit ‘S-TAB’ for it you need not follow that with ‘M-*’. You use ‘M-*’ only when you want to narrow the current set of completion candidates by filtering it with an additional regexp. IOW, ‘M-*’ at the place where you used it can only narrow the choices for the subdirectory. If you then type ‘foo’, you are saying that you are looking for a file or directory that matches both ‘sub’ and ‘foo’.

Here, I think, is what you want to do:

  C-x C-f  s u b  S-TAB  f o o  S-TAB RET

That assumes that there is only one file/directory that matches ‘sub’. If that’s not the case, then you will need to either type some more and use completion (possibly progressive completion, ‘M-*’) or cycle to get to the subdirectory you want. Then, when the minibuffer input shows the complete name for that subdirectory, just hit ‘S-TAB’ (or ‘TAB’) to see all of its files as candidates. (If you cycled to get to the subdir name, then move the cursor first, to show that the subdir is the candidate you want.) Then type ‘foo S-TAB’ to complete to the file you want.

It’s easier to do than to describe. Essentially, you complete a single file or directory name at a time: first the subdir, then the file within the subdir. That’s the way Emacs file-name completion works: The last part of a file-name is completed in the directory named by the first part. When a directory is the minibuffer input and you hit ‘TAB’ or ‘S-TAB’, all of its children (files and subdirectories) are displayed in ‘*Completions*’ as the candidates. But first you need to complete the directory name (‘sub’) itself. Just play with it a bit, hitting ‘TAB’ or ‘S-TAB’ when you have a full directory name in the minibuffer; you’ll see what I mean.

HTH - Let me know what you see, and if you still think you see a bug. – DrewAdams

Thanks for the update …

Your modified sequence does the right thing … Thanks… However, I don’t understand why my sequence does not work. Your sequence is fine if I know a priori what the unique identifier in the filename is, however, I often don’t know, so I want to look at the completion list, and then narrow the search.

The directory ‘sub’ is unique. When I pres ‘S-TAB’ the first time, it is to get a list of all the files in the ‘sub’ directory. I guess it is such habit to just hit ‘TAB’, I forgot that I really typed ‘TAB’ to get find file to stick the ‘/’, after s u b and then I hit the ‘S-TAB’ to get the list of files in the directory in the completions window. I then hit ‘M-*’ to search for the filename with foo in it. I hit the S-TAB’ to get the completion, since the string foo is unique in the filename that I am looking for. However, the string that is returned in my minibuffer is only the filename, it does not include the ‘sub/’ needed to visit the correct file. So emacs opens an empty buffer visiting a file in my home directory with the name of the file that I am looking for from the sub directory.

My dir structure is like this:
    ~/home/
        sub/
           random_prefix1_a
           some_other_prefix_b
           yet_another_c
    ...
           the_file_i_am_looking_for_but_dont_know_the_prefix_foo
    ...
           file_etc

Thanks, IanPerryman

As I said, you do not have to hit ‘M-*’ to match ‘foo’; it is enough to type ‘foo’. But it does not hurt to hit ‘M-*’. I’m sorry, but I cannot reproduce the problem. Perhaps someone else can, and perhaps either they or you can debug it a little. Here is what I see, with directories and files similar to what you describe:

  C-x C-f sub TAB

That shows:

  /home/sub/ [Sole prefix completion]

I type ‘S-TAB’ to see the files in ‘sub’. This is not necessary; you can just type ‘foo’, then ‘S-TAB’ to complete it – but this doesn’t hurt. I then type ‘M-*’, which is also unnecessary, but it does not hurt. I then see:

  Match also (regexp): /home/sub/

I type ‘foo’ (you did not say when you typed ‘foo’, BTW). I type ‘S-TAB’ to complete it. I then see this:

  /home/sub/the_file_i_am_looking_for_but_dont_know_the_prefix_foo [Sole apropos completion]

The file name (non-directory part) is highlighted with face ‘icicle-complete-input’. I hit ‘RET’, and it opens that file. I think that’s just what you described (except I don’t know when you typed ‘foo’), but before you hit ‘RET’ you apparently see only this (no ‘sub’):

  /home/the_file_i_am_looking_for_but_dont_know_the_prefix_foo

Or do you see this (no directory at all)?

  the_file_i_am_looking_for_but_dont_know_the_prefix_foo

You should not see the latter, but it should still work, since the ‘default-directory’ should be /home/sub/.

Question: You did hit ‘S-TAB’ after you typed ‘foo’, right? Since there is only one match, ‘foo’ itself will be highlighted with face ‘icicle-complete-input’ to indicate that. If you then hit ‘RET’ without first completing with ‘S-TAB’, it will open a new file ‘foo’ in directory /home/sub/. But I understand that what happens is that it opens a new file `the_file_i_am_looking_for_but_dont_know_the_prefix_foo’ in directory /home/ (not /home/sub/).

Anyway, I cannot do more without more info from debugging. If you want to do that, you can try. Are you using the default Icicles bindings, so that ‘C-x C-f’ is bound to ‘icicle-find-file’? If so, you can try ‘M-x debug-on-entry read-file-name’ or ‘M-x debug-on-entry icicle-find-file-w-wildcards’. Before you do that, load files icicles-cmd.el and icicles-fn.el, then toggle Icicle mode off, then on – that way, you’re using the source definitions, not the byte-compiled definitions. If, instead, ‘C-x C-f’ is bound to, say, ‘find-file’, then debug either ‘read-file-name’ or ‘find-file’.

Let us know your platform (GNU/Linux? UNIX?). Perhaps someone else can reproduce the problem. – DrewAdams

Sorry for the mess up…. I did not notice your update … my bad. I updated my earlier response without seeing your reply

I am using Red Hat Enterprise Linux (RHEL) I think it is version 4…. the version of emacs is 21.3.1.

You asked “You did hit ‘S-TAB’ after you typed ‘foo’, right?” Yes I did, and it returned the filename, but not the directory. I think the problem only occurs when I use the ‘M-*’ which you have indicated is redundant. After trying it your way (without ‘M-TAB’), it seems to work fine. I can still hit ‘S-TAB’ to get a completion list and then just ‘f o o’ ‘S-TAB’ to get the desired results.

You wrote:

I then type ‘M-*’, which is also unnecessary, but it does not hurt. I then see:

  Match also (regexp): /home/sub/

I get:

  Match also (regexp):

It is blank …. when I type ‘f o o’ it flashes something like … only 1 completion. I then hit ‘S-TAB’ and I get the_file_i_am_looking_for_but_dont_know_the_prefix_foo. I hit ‘RET’ and then I get my empty buffer. If I do a ‘M-x pwd’ I get /home I tried it using emacs -q to ensure that it is not something else in my setup. It is probably something to do with emacs 21.3 and sounds like it is fixed in emacs 22. You can close the issue if you like.

Thanks for the outstanding support! – IanPerryman

Got it! It’s definitely a (great) Icicles bug in Emacs 20 and 21 (but not Emacs 22). Those Emacs versions don’t allow a PREDICATE argument for ‘read-file-name’, so I must switch to ‘completing-read’ for the subsequent (progressive) completions.

The fix is that I need to tack on the directory. So in Emacs < 22, you will see the directory as part of each completion candidate (e.g. in ‘*Completions*’, should you happen to hit ‘S-TAB’ again) instead of in the minibuffer. This is not ideal, but it works. It is not ideal because it is not really file-name completion – you can no longer change directories, for example, once you’ve used ‘M-*’.

You’ve learned a lesson about when to complete (‘S-TAB’) and when you don’t need ‘M-*’, and I learned about a great bug that’s been there for a few months. Thanks! Please try the latest version of icicles-mcmd.el. Thanks for your patience and perseverance. – DrewAdams

Works great … thanks for the fix - Ian


I got following errors with emacs-23.0 and all the elisp files mentioned here have been downloaded from EmacsWiki site on 2007-08-10. Thanks – ThomasLim

An error has occurred while loading `d:/.emacs':

error: Recursive load, d:/emacs/site-lisp/icicles.el,
d:/emacs/site-lisp/highlight.el, d:/emacs/site-lisp/replace+.el, 
d:/emacs/site-lisp/menu-bar+.el, d:/emacs/site-lisp/icicles-mode.el, 
d:/emacs/site-lisp/icicles.el, d:/emacs/site-lisp/highlight.el, ...

Thanks. It should be fixed now. You will need the latest versions of any of these libraries that you use: menu-bar+.el, replace+.el, start.el. Let me know if you still have a problem. – DrewAdams

After updating all the above 3 files, I still have the same problem. If you need more information, just let me know how to obtain it. Thank you. – ThomasLim

Yes, please describe just what you do, starting with emacs -Q, so I can try to reproduce the problem. Are you loading all three files? Are you using start.el? Are you byte-compiling the files? Do you get an error when you byte-compile? Are the byte-compiled files newer than the source files? Just what do you have in your .emacs that causes these files to be loaded? Are you getting the exact same error message as before? Do you have highlight.el? What other files are you loading?

I need a little more information – please try to provide a recipe, starting with emacs -Q.

Try just requiring Icicles: (require 'icicles) – do you run into a problem with that? Are you explicitly requiring replace.el[c]? If so, when are you requiring it? If not, what are you loading that is requiring replace.el[c]?

Thanks. – DrewAdams

Actually this error is a little bit different with the first one because the recursion does not involve replace+.el. I started with emacs -Q, just evaluated (require 'icicles) and got following error:

Debugger entered--Lisp error: (error "Recursive `require' for feature `icicles'")
  require(icicles nil t)
  ...
  require(highlight nil t)
  ...
  require(menu-bar+ nil t)
  ...
  require(icicles-mode)
...

I found that only installing Icicles, highlight.el and menu-bar+.el is sufficient to reproduce the error. And none of them have been byte-compiled. Thanks – ThomasLim

Sorry for all the trouble. For some reason, I don’t get the error, in Emacs 20, 22, or 23, whether byte-compiled or not, even in a virgin directory with emacs -Q, but I think I see what the problem is. Please download highlight.el and menu-bar+.el and try again. Let me know… Thanks – DrewAdams

It is now fixed. Thank you for all your effort. – Thmoas


Just discovered Icy’s C-` in shell mode. Neat! (M-r hurts..). Couple of issues though:

1) It seems to work by scanning the current buffer for shell prompts, which results in all the entries in the ‘*Completions*’ buffer having `[me@host ~]’ (or whatever) prepended to them. I’m not sure this is useful. I think it’s fine to highlight the full line of input, including the shell prompt, in the shell buffer itself, but the prompt should be stripped from the input lines when placed in the ‘*Completions*’ buffer.

Here’s a weird interaction that happens because of this: in directory ‘one’, ‘echo foo’. In directory ‘two’, ‘echo foo’. Now, try to complete on ‘foo’. It completes up to `[me@host ` because the two directories differ, but really they have nothing to do with the command being completed.

2) The ‘*Completions*’ buffer contains duplicate entries, one for each time you previously entered the same command. I don’t think it’s useful to choose between one of n identical entries. Can only one be shown?

Thanks – AvgJoe

Try also ‘C-c TAB’ (‘icicle-comint-command’). That is also an Icicles multi-command, and it has these advantages over `C-`’ (‘icicle-comint-search’):
    • You can access all commands in ‘comint-input-ring’, not just commands that are visible in the buffer. This means you can also access commands in previous sessions.
    • The prompt is not part of the candidate. This should take care of your prompt problem. (BTW, ‘S-TAB’ should nevertheless show you all matches for ‘foo’, regardless of the prompt (directory).)
On the other hand, `C-`’ has this advantage over ‘C-c TAB’:
    • The prompt is part of the candidate ;-). This means, in particular, that you can use ‘C-RET’, ‘C-mouse-2’, etc. to repeat multiple previous commands, or repeat the same command multiple times, without exiting completion. When you use ‘C-RET’ etc. with ‘C-c TAB’, the chosen command is inserted multiple times at the same prompt (e.g. #lslsls), instead of being executed multiple times.
By default, duplicates are removed. And you can toggle this behavior at any time during completion, using `C-$’. Perhaps you previously toggled this and forgot about it? If not, if you find that the default behavior is without duplicate removal or you cannot toggle this, then let me know – that would be a bug.
Keep in mind that these Icicles commands are basically only proof-of-concept functions, to show that it is easy to use Icicles search in different ways etc. They don’t pretend to offer a whole lot in the way of shell interaction functionality. I’m open to useful improvements, but I won’t try to get into sophisticated prompt manipulation and stuff – not worth it for me (but others can try).
See Icicles - Other Search Commands#IciclesShell for more information. HTH. – DrewAdams

When using icicles together with mumamo-mode (see http://www.emacswiki.org/cgi-bin/wiki/MuMaMo) completion in function “mumamo-set-chunk-family” only works partially. Upon selecting a completion candidate the error “Wrong type argument: listp, 1” is thrown.

The relevant debug output is:

[...]
  signal(error ("Wrong type argument: listp, 1"))
  error("%s" "Wrong type argument: listp, 1")
  (condition-case act-on-choice 
(let (...) (setq icicle-candidate-action-fn nil) 
(funcall ... cmd-choice)) 
(quit (icicle-try-switch-buffer orig-buff) (setq last-command last-cmd))
(error (icicle-try-switch-buffer orig-buff) (setq last-command last-cmd) 
(error "%s" ...)))
  (let* ((orig-buff ...) (orig-window ...) (last-cmd last-command)
(icicle-candidate-action-fn ...)) nil 
(condition-case act-on-choice (let ... ... ...) (quit ... ...) (error ... ... ...))
 (setq last-command last-cmd))
  icicle-execute-extended-command()
  call-interactively(icicle-execute-extended-command)
[...]

To reproduce:

1. Install mumamo-mode and start it: e.g.: (load “../../EmacsW32/nxml/autostart.el”) (mumamo-global-mode ‘nil)

2. M-x mumamo-set-chunk-family

3. Select any candidate (in my case, I just hit <Tab> to accept default choice, i.e. “nXhtml Family”)

4. Hit enter: “Wrong type argument: listp, 1”

Without icicles active, no error appears. 31.05.2007 - ClausKlingberg

  1. Try with the latest version of Icicles. If that doesn’t solve the problem, continue.
  2. Identify your Emacs version.
  3. Explain how to download and install the necessary mumamo and nxhtml files.

What happens if you do ‘M-x debug-on-entry completing-read’? What are the arguments to ‘completing-read’, particularly the second argument, TABLE? I suspect that the TABLE argument to ‘completing-read’ might be the problem. If so, I will need to know what form it has (alist, function, etc.) and, if it is an alist, what a typical element in the list looks like.

What happens if you set ‘icicle-bind-top-level-commands-flag’ to ‘nil’? If you don’t see the problem, then you can do that as a workaround. You can also just bind ‘M-x’ to ‘execute-extended-command’, which is less drastic.

If you tell me clearly how to obtain and install the necessary libraries, without also installing Emacs (e.g. EmacsW32), then I will try to take a look. Thx – DrewAdams

Drew,

let me provide you with some more information (see below) - if that’s not sufficient, here’s how to download nxhtml-mode:

Latest version of nxhtml-mode (including mumamo-mode) can be downloaded here: http://ourcomments.org/cgi-bin/emacsw32-dl-latest.pl (see link to zip-file near bottom of page) Installation is described in README file (nothing special from other packages). I’m using v1.03 of nxhtml-mode as of 25/05/2007 with GNU Emacs 22.0.99.1 (i386-mingw-nt5.1.2600) of 2007-04-24

Icicles-mode is up to date (01/06/2007)

Now for some debug info:

I suspect the critical code is starting here, at function completing-read (from mumamo.el):

[...]
      (define-key minibuffer-local-must-match-map [up] up-fun)
      (define-key minibuffer-local-must-match-map [down] down-fun)
      (save-window-excursion
        (mumamo-describe-chunk-family default-name)
        (completing-read prompt
                         mumamo-chunk-family-list
                         nil ; predicate
                         t   ; require-match
                         default-name ;; initial-input
                         (cons 'hist histpos) ;; hist
                         )))))
  (when (= 0 (length chunk-family-name))
    (error "No chunk family given"))
[...]

Since you mentioned the table-variable might be the culprit. From the definition of ‘mumamo-chunk-family-list’ (an alist type variable):

C-h-v ‘mumamo-chunk-family-list’

[...]
The entries in this list has the format

  (CHUNKS-DEF-NAME MAJOR-MODE SUBMODE-CHUNK-FUNCTIONS)

CHUNKS-DEF-NAME is the key name by which the entry is recognized.
MAJOR-MODE is the main major mode used by this entry.
SUBMODE-CHUNK-FUNCTIONS is a list of the functions that does the
chunk division of the buffer.

[...]

Value:
(("nXhtml Family" nxhtml-mode
  (mumamo-chunk-xml-pi mumamo-chunk-inlined-style
   mumamo-chunk-inlined-script mumamo-chunk-style mumamo-chunk-onjs=))
 ("HTML Family" html-mode
  (mumamo-chunk-xml-pi mumamo-chunk-inlined-style
   mumamo-chunk-inlined-script mumamo-chunk-style mumamo-chunk-onjs=))
[...]

BTW: Setting ‘icicle-bind-top-level-commands-flag’ to ‘nil’ makes no difference. HTH, ClausKlingberg

Thanks for the info, Claus. Very interesting problem. Yes, this is an Icicles bug, and I’m not sure of the best way to fix it. I’ve posted a message to the Emacs developer’s list with a question about it. I’ve also provided a quick-and-dirty fix, for now – please try the latest version and let me know.

The problem is a name capture between the HIST parameter of ‘icicle-completing-read’ (to which ‘completing-read’ is aliased when you are in Icicle mode). Mumamo passed (hist . 1), and ‘hist’ is also the name of the parameter of ‘icicle-completing-read’. Although ‘hist’ in (hist . 1) was meant to refer to a global variable ‘hist’, the name was captured by the parameter ‘hist’, and the value was therefore (hist . 1)!

No matter what I name that parameter, say `jk$lj*&’ instead of ‘hist’, if you (or Mumamo or whoever) pass an arg that refers to that name, say (jk$lj*& . 1), then ‘minibuffer-history-variable’ picks up that value, (jk$lj*& . 1), instead of the value of `jk$lj*&’.

The only clean way around this that I can think of is to use a macro instead of a function, but that is unacceptable, because I need to alias ‘completing-read’ to it. I need to have all code that calls ‘completing-read’ pick up the Icicles definition.

For now, I’ve used an ugly hack to fix this for 99.99999999% of the cases: just using a weird parameter name (e.g. `jk$lj*&’). If I hear of a better solution from someone on the emacs-devel list then I’ll do that.

BTW, you also have another reported bug at StaleIssues below. I marked it as stale because I never heard back from you. That too is about nxhtml. Please take a look. – DrewAdams

Thanks for looking into this. Seems like a tricky issue not easily resolved. However, I can confirm your workaround fixes things for now; (which makes me happy since I became to rely heavily on Icy + nxhtml).

I also updated my other issue about nxhtml-completion - see below


S-TAB gets the error message ‘icicle-add-key+cmd: Wrong type argument: symbolp, 32’. – ppp-80-47-127-162.lns.access.uk.tiscali.com

Please provide a complete recipe to reproduce the problem, starting with emacs -Q. Otherwise, I cannot follow. I don’t know what you did, or when.
You might want to do this, to help track down what’s happening:
    1. Load icicles-cmd.el, even if you’ve already loaded Icicles.
    2. M-: (define-key icicle-mode-map "\M-x" 'execute-extended-command) – This makes debugging errors easier.
    3. M-x set-variable debug-on-error t
    4. Do whatever you did to provoke the error.
I don’t have much hope that I will be able to fix this for you. Emacs 23 uses Unicode, and AFAIK, it changes stuff that has to do with keymaps quite a bit. The Icicles code that provides key completion works with the keymap features and functions of Emacs 22. This is a pretty hairy area, and I have no Emacs 23 source code (and don’t have the time to investigate it).
As a workaround, you can forego key completion, by changing (when (fboundp 'map-keymap) just before the ‘defvar’ for ‘icicle-complete-keys-alist’ to (when (= emacs-major-version 22). That will at least get you up and running, without key completion.
When Emacs 23 comes out, replacing 22, I’ll take a look at the key-completion code and try to fix it to work with Emacs 23. If that’s not feasible, then I’ll pull it out. That would be a shame, but I have no confidence that Emacs 23 will be amenable to key completion in the way the Emacs 22 is. We’ll see…

I tried the above to get extra debuging info but it didn’t seem to make any difference. Same error message, no backtrace, nothing extra in Messages.

Anyway, for clarity, here are the steps to reproduce. On startup, switch to the Messages buffer by typing Mes S-TAB. Works. In a shell buffer, try TAB completion. Works. In that same shell buffer, then try apropos S-TAB completion. Fails with above error messages. i.e., it only seems to affect apropos on files.

I tried your suggested change re: fboundp map-keymap, but seems to just dissable apropos completion all together, which isn’t a step forward.

While byte compiling, I did get these messages which seem related to the unicode stuff:

icicles-cmd.el:4087:32:Warning: ‘char-valid-p’ is an obsolete function (as of Emacs 23.1); use ‘characterp’ instead. icicles-cmd.el:3941:35:Warning: ‘generic-char-p’ is an obsolete function (as of Emacs 23.1); Generic characters no longer exist

In end of data: icicles-cmd.el:4202:1:Warning: the following functions are not known to be defined: icicle-kmacro-action, dired-get-file-for-visit, diredp-find-a-file, diredp-find-a-file-other-window, synonyms-ensure-synonyms-read-from-cache, apropos-function

It looks at least like characterp is available in emacs 22.

I can obvioulsy appreciate that you don’t want to be working on a version of emacs beyond the one which hasn’t even been released yet. I just wanted to mention that emacs 23 is the only one available where the fonts are antialiased, and therefore more people are using it than would otherwise. Packages for v23 are available for Linux distros, for example, where there’s no packages for v22.

Oh yeah. This is a new bug for me, I just updated icicles (same version of emacs). I would guess the last version of iciles was from about a month ago, if that helps.

Thanks for looking Drew! – ppp-80-47-127-162.lns.access.uk.tiscali.com

I’m sorry, but I just don’t have the time or resources to try to track this down. Here is what I can offer, in hopes it helps somewhat.
    1. You should have gotten a backtrace if you set ‘debug-on-error’ to ‘t’. Check its value and check the binding of ‘M-x’.
    2. I suspect you’re confused about ‘S-TAB’, but there could also be a bug. Please be clear about what you did in the shell buffer. It sounds like you were not using minibuffer completion, but were just using ‘TAB’ and ‘S-TAB’ at the top level. I say that because 1) you didn’t say what you did, 2) ‘S-TAB’ at top level does key completion, which is what calls `icicle-add-key+cmd’, and 3) you say that adding ‘fboundp’ for ‘map-keymap’ disabled “apropos completion”. ‘S-TAB’ as apropos completion is completely independent from its use for key completion; for apropos completion, it is a minibuffer binding, not a top-level binding, and it takes effect only during minibuffer (i.e. input) completion. I’ve added the (fboundp 'map-keymap), so you need not do that. It should not affect (apropos) minibuffer completion at all; it should only disable key completion, that is, use of ‘S-TAB’ at top level.
    3. Don’t worry about the byte-compile warnings. However, the first ones you mention do indicate that Emacs 23 has changed considerably wrt the stuff I use for key completion, which was written only a couple of months ago. FWIW, the calls to ‘char-valid-p’ and ‘generic-char-p’ were suggested by the main Emacs developer of Emacs 23! I suspect they changed that after some discussion I had with that developer about some problems I ran into.
    4. There is lots of stuff in Emacs 22 that is not yet in Emacs 23, and vice versa. The former leads to some of your byte-compiler warnings. I cannot support Emacs 23 now. If you can get some use from Icicles with Emacs 23, that’s good, but if you cannot, I’m not sure how much help I can be. I’m available for questions, of course.
    5. That’s too bad about the anti-aliasing. I know what you mean. I use Emacs mostly on MS Windows, and there Emacs is able to take advantage of Windows anti-aliasing (e.g. ClearType font smoothing). I notice that that works for Emacs 20 and 22, but not for Emacs 21, for some reason. If you are not on MS Windows, then I guess you’re out of luck on that, and you’ll need to stay with Emacs 23 to get anti-aliasing.
Sorry I couldn’t be more help. – DrewAdams
P.S. I added your IP as a signature for you, so I and readers can keep track of who reported what. Feel free to change it to a name of some sort.

After a long delay, I finally took a brief look at Emacs 23. Though I think there is some confusion in your bug report, I did see and fix a bug that I think is what you stumbled upon. HTH. – DrewAdams


I got an error. – rubikitch

% emacs-snapshot -batch  --no-site-file -q -L ~/emacs/lisp/icicles -l icicles.el 
-eval '(setq debug-on-error t)' -f icicle-mode
...
Turning ON Icicle mode...
Debugger entered--Lisp error: (void-function menu-item-any-version)
...
  icicle-rebind-completion-maps(t)
  icicle-mode(toggle)
  call-interactively(icicle-mode)
  command-execute(icicle-mode)
  command-line-1(("-L" "/m/home/rubikitch/emacs/lisp/icicles" "-l" "icicles.el" 
"-eval" "(setq debug-on-error t)" "-f" "icicle-mode"))
  command-line()
  normal-top-level()

Duh! Should be OK now. I copied a macro from Lisp:menu-bar+.el and renamed it by adding the prefix icicle-, but I forgot to add the prefix everywhere. Since I use menu-bar+.el, I didn’t notice the problem. Thanks! – DrewAdams

The new completions display with multiple columns and shrink fit windows is really nice! Here’s something weird though: If I split the windows M-x 3, and then in the left window activate some completion, such as switch-buffer and TAB, the right window shows the completions and both windows shrink fit to the contents of the buffer list (a couple of lines). The mini buffer now takes up the whole screen. It all seems to go back to normal when the compltion is done.

However, when I try the same thing with some shell mode directory completion, it works if I do it within the right window pane, i.e. the layout is weird but it returns to normal when completion is done. But if I try initiating completion in the left window buffer, the completions are left active in the right window when the completion is done.

I’m not sure what I expect here. I guess it make sense to use the ‘other’ window temporarily for completions, but It may also make sense to use just the bottom half of the initiating window, or a wide, low window accross the whole frame (if that’s possible). Ideally, everything should return to the state it was when completion is finnished. Thanks. – ppp-80-47-127-162.lns.access.uk.tiscali.com

This should be fixed now. Please try the latest version of Lisp:icicles-fn.el. Thx for the bug report. – DrewAdams

Thanks a lot [for ‘icicle-apropos-complete-and narrow’]. Still there is problem when user submits completion (either by RET or SPC when there is sole completion) last character (RET/SPC) is entered in buffer that is opened afterwards. – MarianSchubert

I’m sorry, but I don’t understand. Please try to give a clear recipe, so I can reproduce and understand the problem. – DrewAdams

Let’s say that i have X buffers already opened and 2 of them are test_customer.py and test_user.py and i hit C-x b then i enter ‘tes’ + C-SPC + ‘cus’ now it says i have Sole completion so i hit RET and it switches correctly to test_customer.py buffer but RET key also ends up in real (test_customer.py) buffer so it’s instantly marked as edited (by new newline at cursor position caused by RET). BTW this doesn’t happend when C-x b is bound to original emacs binding (switch-to-buffer) – MarianSchubert

I don’t see what you describe, following your recipe exactly (except ‘S-SPC’ instead of ‘C-SPC’, which is not bound), and starting with emacs -Q. Perhaps you are leaving something out? I tested with both Emacs 20 and 22, with ‘pop-up-frames’ both ‘nil’ and ‘t’.
I suspect that what you mean is that when you hit ‘RET’, it opens a buffer named ‘cus’. If that is what you mean, then see above, where I say “Keep in mind…”. If ‘C-x b’ is bound to ‘icicle-buffer’ or to ‘switch-to-buffer’, then it uses lax completion, to enable you to type any buffer name you want (e.g. ‘cus’) and open a new buffer. That means that when a sole completion is identified, you must complete your input (‘cus’), using ‘S-TAB’, to that sole completion (`test_customer.py’). Otherwise, when you hit ‘RET’, your partial input (‘cus’) is taken as the name of a new buffer.
If you want strict completion for buffer switching, set `icicle-buffer-require-match-flag’ to ‘partial-match-ok’. Then, use ‘S-RET’ instead of ‘RET’. See Icicles - S-RET.
If I’m still misunderstanding you, please try again to describe exactly what you do, starting with emacs -Q. Include your Emacs version number. – DrewAdams

`mplayer -speed 0.3 http://maio.cz/~maio/icicles.mpg` 😊 before switching to test_customer.py buffer there is “customer” on first line (i leave cursor in middle of that word) and after switching (using icicles-buffer) to another buffer and back there is “cust” on first and “omer” on second line so RET (which i hit in minibuffer to confirm correct completion after “’te’ + S-SPC + ‘cu’ + S-SPC” results in “test_customer.py [Sole apropos completion]”) ends up in buffer and not in minibuffer. (GNU Emacs 21.4.1 and 22.0.95.1) – MarianSchubert

Sorry, it’s still not clear to me exactly what to do to reproduce this. Try to go slowly and explain each thing you do, starting with emacs -Q.
Are you saying that “test_customer.py [Sole apropos completion]” appears in a buffer other than the minibuffer? If so, that is definitely a bug. Please help by describing in detail what you do.
You say that you use ‘RET’ after you see “Sole apropos completion”, but you must use ‘S-RET’, not ‘RET’ to exit with partial input and have it complete (see Icicles - S-RET). Start by seeing if it works to use ‘S-TAB’ and then ‘RET’, after you see “Sole apropos completion”. If that works, then you can try to use just ‘S-RET’ (without ‘S-TAB’), provided that you have customized `icicle-buffer-require-match-flag’ to ‘partial-match-ok’.
I couldn’t watch your video either; perhaps you can post it again without MPG-4. I use IrfanView or MS Windows media player, and they don’t support that format.
I would like to help you, and I’d like to fix what sounds like it might be a bad bug (minibuffer messages appearing in another buffer), but I need clearer, step by step instructions from you. Please go slowly; that will also let you see clearly whether you are hitting ‘RET’ during minibuffer input or after input is finished and focus has returned to your buffer. Thx – DrewAdams

http://www.youtube.com/watch?v=ElvWzuQwZhs

in video i run emacs without evaluating .emacs (emacs -q -L /home/maio/.emacs.d/libs/icicles .emacs). i just evaluate part with my icicles bindings (so SPC is icicle-apropos-complete-and-narrow because i use it a lot), then i create 2 buffers test_customer.py and test_user.py. i write word “customer” to test_customer.py and leave my cursor in middle of that word (i do same for test_user.py) and then switch from test_user.py to test_customer.py using these keystrokes: “C-x b te SPC cus SPC RET” and test_customer.py is instantly edited and it’s content is “cust\nomer”. then i switch from test_customer.py to test_user.py using: “C-x b te SPC use SPC SPC” and test_user is also edited after switching and it’s content is now “u ser”. So in first case last key (RET) which i hit in minibuffer ends up in test_customer.py buffer and in second case last key (SPC) ends in test_user.py buffer. – MarianSchubert

I’m able to reproduce the problem now. I don’t have time now to look into it, but I will when I get a chance. It looks like the final ‘RET’ or ‘SPC’ is not needed for switching buffers in this context, so those extra keystrokes insert a newline or a space. – DrewAdams
Should be OK now; please try the latest Lisp:icicles-mcmd.el. FYI, the problem was this:
    • ‘icicle-narrow-candidates’ was showing the minibuffer message [Sole completion: ...], using ‘minibuffer-message’, which displays for a fixed time.
    • ‘icicle-narrow-candidates’ (‘M-*’) takes a shortcut to throw to top level (which is good).
So, you were already at the top level, switched to the correct buffer, when you hit ‘RET’ or ‘SPC’. That of course just inserted a newline or space. I suppressed the message, which was useless anyway.
BTW, although ‘S-SPC’ (‘SPC’ in your case, since you’ve rebound ‘icicle-apropos-complete-and-narrow’) does everything you need, keep in mind that you can hit ‘S-TAB’ instead of ‘S-SPC’, to simply complete, and then hit ‘RET’. That’s important, in case you didn’t want that sole completion: you can still edit your input to get what you really wanted. If you hit ‘S-SPC’, then you get what you asked for, whether or not it was what you really wanted. Thx for your report. – DrewAdams

Just updated my icicles and now I’m getting an error when trying to complete in shell-mode. e.g. ‘ls ~/.emacs.d/icicles/ici <TAB>’ completes up to ‘icicles’. TAB again gets the error message ‘Symbols value as variable is void: minibuffer-completing-symbol’.

This is with emacs 23. The variable minibuffer-completing-file-name exists, but that’s the only variable beginning with minibuffer-completing* – ppp-80-47-127-162.lns.access.uk.tiscali.com

That is in function ‘icicle-completion-setup-function’, which is almost identically ‘completion-setup-function’ from vanilla Emacs 22. In particular, the part that includes ‘minibuffer-completing-symbol’ is present in the latest Emacs-22 source file, simple.el: http://cvs.savannah.gnu.org/viewcvs/emacs/emacs/lisp/simple.el?rev=1.852&view=log.
So, I don’t know what to tell you. Apparently Emacs 23 has changed that code. I don’t use Emacs 23 or try to support it yet. I’ve changed that particular test to (and (boundp 'minibuffer-completing-symbol) minibuffer-completing-symbol), but I’m not sure that will be much better. Let me know.
If you want to track down the Emacs 23 code for ‘completion-setup-function’ and send it to me, I’ll take a quick look, with no guarantee. I don’t want to get into a general attempt to support an Emacs release that I don’t have and use. Thx – DrewAdams
Great. That worked! Thanks. – ppp-80-47-127-162.lns.access.uk.tiscali.com

Is there a way to have commands executed from the minibuffer (and expanded by apropos completion) added to the command history. At the moment only commands expanded by standard prefix completion are added. Is this a bug or a feature (or maybe I just did miss a configuration option?)?

I use the current icicles version and could verify this behaviour for emacs22 on windows nt and linux. – Jost

Thanks for the report, Jost. I don’t see that bug. In both Emacs 20 and 22 on Windows XP, the command ‘forward-word’ is available at the beginning of the command history after doing this (apropos completion):

 M-x for.*word S-TAB
 RET

That is no different from doing this (prefix completion):

 M-x forward-wor TAB
 RET

What is your binding of ‘M-x’ (use ‘C-h k M-x’)? Is it ‘icicle-execute-extended-command’? Do you see a difference in behavior if you customize ‘icicle-bind-top-level-commands-flag’ to ‘nil’ before loading Icicles and entering Icicle mode? If that option is ‘nil’, then ‘M-x’ is bound to the standard command ‘execute-extended-command’, not to ‘icicle-execute-extended-command’. A difference in behavior could point to ‘icicle-execute-extended-command’ as the culprit.

FWIW – One thing to keep in mind: Don’t confuse the use of input in the minibuffer via, say, ‘C-RET’ during an Icicles multi-command with its final use as input. That is, if you don’t finish a command with ‘RET’ (or ‘S-RET’), then your input is not recorded in a history list. Command ‘icicle-execute-extended-command’ (‘M-x’) is in fact a multi-command, so if you use, say, ‘C-RET’ to execute ‘forward-word’ and then use ‘C-g’ instead of ‘RET’ to end ‘M-x’, ‘forward-word’ is not added to the history. That is so, regardless of whether you use prefix or apropos completion. I doubt that this is what you are reporting, but I thought I’d mention it, just in case.

Please provide an exact recipe to reproduce the problem you see. Don’t forget to mention how you access the command history (or provide the beginning of the value of ‘command-history’). Thx - DrewAdams

Hi Drew,

thanks for your quick response. I did the following

  M-x foward-wo TAB  
  -> previous command is forward-word
  M-x kward-wo  S-TAB
  -> previous commands are backward-word forward-word
  M-x line S-TAB M-* beg S-TAB 

→ ‘beginning-of-line’ executed and previous commands are still: ‘backward-word’, ‘forward-word’.

O.K. the problem seem only to exist if i narrow the search down, standard apropos-completion works the way you mentioned. Does this give you a hint? It seems that ‘M-*’ is hardwired to my fingers, that I didn’t notice its use earlier.

I did check the command history by using ‘M-x M-p’ (multiple times) and then ‘C-g’. ‘list-command-history’ shows all three commands with arguments.

My standard binding for ‘M-x’ was ‘icicles-execute-extended-command’. Using ‘execute-extended-command’ (via setting ‘icicle-bind-top-level-commands-flag’ to nil) did make no difference. – Jost

Hehe… ‘M-*’ is hardwired to my fingers” – I’m amazed that there are already people who have habits that include Icicles… Thanks for a clear bug report. Please try the latest version of icicles-mcmd.el. – DrewAdams


Is there a way to speed up or just selectively load icicles? I probably only use about 10% of its combined power (minibuffer for commands and file expansion almost exclusively) and would prefer 10% of the load time:

From dope.el:

    [471.65ms for line 73 of file /Users/ryan/Bin/elisp/emacs.el at file-depth 0]
     (icicle-mode 1)
    [393.00ms for line 72 of file /Users/ryan/Bin/elisp/emacs.el at file-depth 0]
     (require (quote icicles))

RyanDavis

I don’t think there is an easy way to reduce the initialization time. You can try tweaking things, or perhaps someone else has a suggestion. I don’t plan to try packaging it in optional pieces (with the possible exception of icicles-cmd.el, some of which could be made optionally loadable).

Make sure you byte-compile the libraries, of course, or your load time will suffer (as well as the time to enable Icicle mode).

What version of Emacs do you use? If you use Emacs 22, then there is a significant hit each time you enable or disable Icicle mode. There’s nothing I can do about that, AFAIK – I’ve discussed it on emacs-devel@gnu.org. At least I found a way to remap commands instead of substituting key definitions; the latter takes incredibly long in Emacs 22 for ‘self-insert-command’ (there are 80 zillion things bound to it).

It also depends how you use Emacs. If you open Emacs often, a la vi, or you enable and disable Icicle mode often, then yes, I can see how it would be bothersome. I load Emacs once a day, at the most, and I stay in Icicle mode. Less than a second to load Icicles and enable Icicle mode is not too much when you use it that way, IMO.

Sorry I don’t have a good answer for you. As I say, perhaps someone else has a suggestion. – DrewAdams

FYI I use DumpingEmacs for faster Emacs startup, and I stay in Icicle mode. – rubikitch


--- icicles-mcmd.el	2007/01/15 16:43:26	1.1
+++ icicles-mcmd.el	2007/01/15 16:44:51	1.2
@@ -1868,7 +1868,8 @@
   (let ((frame-with-focus (selected-frame))
         cand-symb)
     (if (eq (current-buffer) (get-buffer "*Completions*"))
-        (setq cand-symb (intern-soft (icicle-current-completion-in-Completions)))
+        (setq cand-symb (intern-soft (icicle-transform-multi-completion
+                                      (icicle-current-completion-in-Completions))))
 
       ;; If no last candidate, then reset to first candidate matching input.
       (unless (stringp icicle-last-completion-candidate)
@@ -1878,7 +1879,8 @@
                                      'icicle-prefix-candidates
                                    'icicle-apropos-candidates)
                                (eq icicle-current-completion-mode 'apropos)))
-      (setq cand-symb (intern-soft icicle-last-completion-candidate)))
+      (setq cand-symb (intern-soft (icicle-transform-multi-completion
+                                    icicle-last-completion-candidate))))
 
     ;; If this is a call to `icicle-execute-menu-command'
     ;; (defined in `icicles-menu.el'), then 
     ;; use command associated with a menu item.
     ;;  `icicle-menu-items-alist' is set in

I think ‘cand-symb’ should be transformed when using multi-completion. – rubikitch

Yes, I think so too. Thx - DrewAdams


(progn
  (delete-other-windows)
  (display-buffer (get-buffer-create "*icicles debug*"))
  (split-window)
  (let ((cands '((("clone" "CLONE")) (("abs" "ABSOLUTE VALUE"))))
        (icicle-candidate-help-fn
         (lambda (cand)
           (with-current-buffer "*icicles debug*"
             (goto-char (point-min))
             (insert cand "\n"))))
        (icicle-list-join-string " = ")
        (icicle-list-end-string "")
        (icicle-list-use-nth-parts '(1))
        (icicle-show-Completions-initially-flag t))
    (completing-read ">" cands)))

When pressing: c, M-C-RET, M-k, a, M-C-RET

Second M-C-RET should be ‘abs’. – rubikitch

Should be OK now. – DrewAdams


I use user-defined ‘icicle-candidate-help-fn’ (in icicles-rcodetools.el) and sometimes occurred “No help” message. This patch remedies the problem. – rubikitch

--- icicles-mcmd.el	2007/01/13 14:51:39	1.1
+++ icicles-mcmd.el	2007/01/13 14:52:58
@@ -1825,7 +1825,7 @@
   (let ((frame-with-focus (selected-frame))
         cand-symb)
     (if (eq (current-buffer) (get-buffer "*Completions*"))
-        (setq cand-symb (intern-soft (icicle-current-completion-in-Completions)))
+        (setq cand-symb (intern (icicle-current-completion-in-Completions)))
 
       ;; If no last candidate, then reset to first candidate matching input.
       (unless (stringp icicle-last-completion-candidate)
@@ -1835,7 +1835,7 @@
                                      'icicle-prefix-candidates
                                    'icicle-apropos-candidates)
                                (eq icicle-current-completion-mode 'apropos)))
-      (setq cand-symb (intern-soft icicle-last-completion-candidate)))
+      (setq cand-symb (intern icicle-last-completion-candidate)))
 
     ;; If this is a call to `icicle-execute-menu-command'
     ;; (defined in `icicles-menu.el'), then 
     ;; use command associated with a menu item.
     ;;  `icicle-menu-items-alist' is set in
@@ -1847,7 +1847,7 @@
     ;; If this is a key-completion candidate, then get the true
     ;; command from the candidate.
     (when (boundp 'icicle-completing-keys-p)
       (string-match "\\(.+\\)  =  \\(.+\\)" icicle-last-completion-candidate)
-      (setq cand-symb (intern-soft (substring icicle-last-completion-candidate
+      (setq cand-symb (intern (substring icicle-last-completion-candidate
                                               (match-beginning 2) (match-end 2)))))
 
     ;; Provide the help appropriate for the given type of candidate.

Not a bug ;-). Actually, the story is more interesting than that. I use ‘intern-soft’, not ‘intern’, so that I can privilege describing existing symbols. By using ‘intern-soft’ I can avoid creating symbols that name buffers etc. Symbols are described in this priority order:

  1. those for which ‘icicle-candidate-help-fn’ is defined
  2. those naming functions
  3. those naming variables
  4. those naming faces
  5. those with plists

However, I’ve improved the code, with your request in mind. Now, if an existing symbol is not found, one is created with that name, and it is described, so you should get the behavior you wanted.

Also, I’ve added description of file names, and I describe buffer and file candidates whether the candidate is a symbol or a string. If a buffer is visiting a file, the buffer is described; otherwise, the file is described. You might want to bind the new command for describing a file to some key. Library setup-keys.el uses ‘C-h M-f’.

There is currently an Emacs 22 bug (which I’ve reported) that the code tries to work around. However, the workaround is not 100%: The file of the current buffer gets described, not the buffer itself. That minor problem will go away when the Emacs bug is fixed.

As always, thanks for your feedback. – DrewAdams


[2006/12/23] GNU Emacs 22.0.50.1 (i486-pc-linux-gnu, GTK+ Version 2.8.20) of 2006-12-17 on love, modified by Debian

Evaling:

 (progn
   (shell-command "touch /tmp/hoge /tmp/boke")
   (read-file-name "File: " "/"))

Input:

 /tmp/e [S-Tab]
 M-* bo [S-Tab]

Output: “boke

I think the output should be “/tmp/boke”. This problem prevents me from opening files in other directory with ‘S-TAB’ and ‘M-*’. – Anonymous

Excellent bug! I was using only ‘completing-read’, not also ‘read-file-name’, in ‘M-*’. Please give the latest version a try, and let me know. Thx – DrewAdams

The problem is fixed, thank you!! – Anonymous


I tried it, but occurred this error.

~/emacs/lisp/icicles% emacs-snapshot -batch --no-site-file -q -L 
       ~/emacs/lisp/icicles -l icicles
Loading subst-ksc...
Loading subst-gb2312...
Loading subst-big5...
Loading subst-jis...
Unknown button type `help-xref'

– Anonymous

Please try the latest icicles-mcmd.el. Let me know if it is fixed, so I can close this bug. This comes from trying to make the library work with multiple Emacs versions. I had a test that filtered out Emacs 20 but not also Emacs 21; ‘help-xref’ is defined in Emacs 22 (or perhaps a different version of Emacs 21 from what you have).

Thx – DrewAdams

I successfully loaded and started to use icicles, thx. – Anonymous


[2006/12/19] I downloaded icicles*.el with get-icicles.sh, but faced recursive ‘require’ problem.

~/emacs/lisp/icicles% emacs-snapshot -batch --no-site-file -q -L 
    ~/emacs/lisp/icicles -l icicles
Recursive `require' for feature `icicles-mode'
zsh: exit 255   emacs-snapshot -batch --no-site-file -q -L 
    ~/emacs/lisp/icicles -l icicles
~/emacs/lisp/icicles% emacs-snapshot --version
GNU Emacs 22.0.50.1
Copyright (C) 2006 Free Software Foundation, Inc.
GNU Emacs comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of Emacs
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.

– Anonymous

Thanks for trying Icicles. This should be fixed now – let me know if it isn’t. Please try the latest version. – DrewAdams


Whenever I type a digit and press tab to complete it, I get following message:

icicle-prefix-complete: Wrong type argument: symbolp, (lambda nil “Select a completion to insert if there is one, otherwise run whatever command would normally be bound to the key sequence.” (interactive) (completion-run-if-within-overlay (quote completion-select) (quote completion-use-hotkeys)))

Thomas

I’ll need some more information to find this problem. Please give me a specific recipe, starting with emacs -q --no-site-file. I can use prefix completion with command names that start with numerals (e.g. ‘1on1-emacs’) with no problem. Also, I find no occurrence of ‘completion-run-if-within-overlay’ or ‘completion-use-hotkeys’ in either the Icicles code or the vanilla GNU Emacs Lisp or C code. So, I suspect that maybe something else you are loading is causing this problem, not Icicles. What Emacs version are you running? Are you running a recent version of Icicles?

I even tried googling for ‘completion-use-hot-keys’, but couldn’t find it anywhere. However, I was able to locate ‘completion-run-if-with-overlay’ – it is in TobyCubitt’s PredictiveMode/CompletionUI code (Lisp:completion-ui.el).

So, the first step is to try to reproduce the problem with Icicles alone, starting with emacs -q --no-site-file. I’m pretty confident you won’t reproduce it. It’s entirely possible that PredictiveMode/CompletionUI and Icicles don’t play too well together. However, I believe that TobyCubitt himself uses Icicles, so you might want to contact him about this problem. He is likely to know more than I about how to use the two together. After that, I’ll be glad to try to help, if I can. Thx – DrewAdams

Thanks. I get above error message only when I load ‘completion-ui’ with ‘completion-use-hotkeys’ set as non-nil. I’ll look into it now. – Thomas

I’ve corresponded with TobyCubitt about it a bit. I think he might also be looking into it now. We’ll try to get it fixed one way or the other, or at least understand why we can’t or shouldn’t ;-). – DrewAdams

This should now be fixed. Let me know if it’s not.

FYI – TobyCubitt pointed out that he binds anonymous functions to characters in the minibuffer completion maps. Icicles tests ‘last-command’ and ‘this-command’ symbols in various places, to see if the command was a cycling command, a completing command etc. Of course, an anonymous function is not a symbol, so (get last-command 'icicle-cycling-command) was raising an error.

It turns out that there is some vanilla EmacsLisp code that makes the same assumption that Icicles made that the last command was a named command. I’ll report that to Emacs development, so those bugs get fixed too. Thx! – DrewAdams


I usually have two or more windows open in a frame. When I quit the ‘*Completions*’ buffer, it kills my window, even if it wasn’t what created it. I fixed this behavior in my local copy (in a kind of crocky way), but maybe it should be dealt with more widely. The package BrowseKillRing deals with this well. – saccade

I’ll try to help, but you’ll need to give me some more information. What version of Emacs? Do you have the latest version of Icicles? I think you’re saying that you use completion, and then end completion (using ‘C-g’ or ‘RET’?), and one of the windows (which one?) you had open originally disappears (so you only have one window in the end). Is that right? What do you mean by “it wasn’t what created it” – what created what?

I wasn’t able to reproduce your problem (if I understand it correctly). Can you give me an exact recipe to reproduce this, starting with emacs -q, and specifying which window is selected when you use completion, how you “quit the ‘*Completions*’ buffer”, and which window disappears?

I don’t see the connection with BrowseKillRing; perhaps if you explain that, it will help also. BrowseKillRing does not use completion, AFAIK.

Telling me how you fixed your local copy might help me understand the problem better also. Thx – DrewAdams

C-x 3

(add-to-list  'load-path "~/rep/src/emacs/icicles/") C-x C-e 

(load "icicles")  C-x C-e 

(icy-mode 1)  C-x C-e 

M-x foo S-tab C-g

C-x b *Completions*

q (or C-x k C-m)

This kills the window, with the message “icicle-abort-minibuffer-input: No recursive edit is in progress”

I downloaded icicles from http://www.emacswiki.org/cgi-bin/wiki/download/ yesterday.

(GNU Emacs 22.0.50.1 (powerpc-apple-darwin8.5.0) of 2006-03-22)

BrowseKillRing is only relevant insofar as it has graceful handling of window behavior. It pops things up in other windows, and when I get rid of it, it only kills them if it created the window itself. Icicles seems to assume that it created the window that Completions is displayed in, and when I dismiss it, it wipes out the window.

To fix it, I just rebound C-x k to the normal kill-buffer command. – saccade

Hmm. Well, I’ve uploaded a change that I think will take care of this when you use ‘q’ in ‘*Completions*’. However, this “fix” is a bit against my better judgement, to be honest.

Also, if you use ‘icicle-kill-buffer’ to kill ‘*Completions*’, instead of using ‘q’, then you will see the same behavior as before. This behavior is normal, IMO: the ‘*Completions*’ window should be removed when completion is finished. Plain ‘kill-buffer’ does not use ‘completing-read’, so it does not remove the ‘*Completions*’ window; ‘icicle-kill-buffer’ does use (Icicles) ‘completing-read’, so it does remove the ‘*Completions*’ window. I see no reason why ending completion should not remove the ‘*Completions*’ window (as you say, it was created and displayed by Icicles in this case).

I think the real issue is perhaps this: ‘*Completions*’ might not always be displayed in a new window; instead, depending on your setup, it can perhaps sometimes reuse an existing window. In my own setup (OneOnOneEmacs), it always uses a new window (a separate frame, in fact), so it always makes sense to delete that window afterward. I can, if needed, ensure that ‘*Completions*’ is always displayed in a new window, but I’m not sure that would be appreciated by everyone. Currently, I just use ‘with-output-to-temp-buffer’ to display it. I don’t bother using ‘temp-buffer-show-function’ to ensure that a new window is created for the display.

I’m curious as to what your use case really is. What you described seems like a strange way to work (nothing wrong with strange ways of working; that’s what led to things such as Icicles!). I understand that the recipe was just to reproduce the bug, but I wonder what you were actually doing (trying to do) that led you to do this. I’m curious, in particular, why anyone would switch to buffer ‘*Completions*’ outside the context of completion, and then not want the ‘*Completions*’ window to be removed when its buffer is killed.

Please let me know how you were working, so I can understand your use case. In my thinking (so far), ‘*Completions*’ is tied to completion, and I always want to remove its window when completion is finished.

It’s possible that I won’t want to change Icicles to accomodate your use case, depending on what it is, but please let me know about it. And let me know if the ‘q’ fix works for you, at least.

Thx for the bug report. – DrewAdams

So, here is the workstyle that leads to this issue. I have a bunch of desktops, about 4 or 5 of which normally have an emacs frame open filling the entire desktop. The frame is subdivided into three or four columns, each of which is divided into one to three rows. These contain things like chat, dired, the buffer list, gud, interpreters, notes, the kill ring, todo lists, and of course code. I do this because this way emacs can make sure that nothing is partially overlapping anything else, which is a pet peeve of mine. (Unsuprisingly I also have an absurdly pimped-out balance-windows function.) Something I have in my mind basically all the time is what stuff is in what part of the screen on what desktop. The fact that you develop this on OneOnOneEmacs explains a lot – as an experiment I tried using Icicles with a bunch of frames rather than a bunch of windows, and sure enough, if I use it that way everything is totally copacetic. Unfortunately, this would require me to change my entire MO.

I suggest that as an experiment, you try using a bunch of windows for a little while where you might use a bunch of frames, both with and without Icicles. You’ll probably notice that when you turn on Icicles, when you’re using its capabilities (in find-file, extended-command, etc.) the contents and configuration of the windows start rearranging themselves rather unpredictably. This is why I kept quitting the Completions buffer – it kept showing up where I didn’t expect it. Whatever you did seems to have partially ameliorated the problem – I turned icicles back on, and have been working with it for the past half-hour or so, and for whatever reason it’s better behaved since the update. Now the windows only unexpectedly rearrange themselves temporarily – when I’m done using Icicles they’ve been going back to normal.

I know that my window-using habits probably lie in the tail of some distribution, but there are a bunch of people who use windows at least a bit. – saccade

Thanks for the clear explanation. I don’t have the time now to look into this, but when I do, I will. Probably what I’ll do first is make ‘*Completions*’ always open in a new window, instead of reusing an existing window. IIUC, that might take care of the problem.

FWIW, I suspect that there are many more people using Emacs the way you do (maximized frame(s) with multiple windows) than the way I do (OneOnOneEmacs). Thx – DrewAdams

I’m sorry to say that I looked into this, but I don’t see an easy way to change the behavior so that it DTRT in all contexts. I did spend some time on this, but it’s not obvious to me. If you experiment and discover a good tweak, I’m open to looking at it.

Also, if you can debug a little, to determine more about the window rearrangement you mention, then I can look at that a little more. As it stands now, it’s not clear to me what happens – I haven’t seen it.

I’m curious about one thing, also: Don’t you see similar behavior with vanilla Emacs? ‘*Completions*’ is displayed in an existing window (if you have more than one window), and that window is chosen unpredictably. When you quit completion, ‘*Completions*’ disappears and is replaced by another buffer (generally the one that was last in that window). I don’t see a difference in behavior, now, between Icicles and vanilla Emacs in this regard.

I did make some other changes (bug fixes), as a result of playing with Icicles in a maximized single frame (without non-‘nil’ ‘pop-up-frames’). In particular, I don’t think `icicle-help-on-(next|previous)-(apropos|prefix)-candidate’ and `icicle-(next|previous)-(apropos|prefix)-candidate-action’ were working properly in that context before.

I’m moving this to ClosedIssues, since I don’t think there’s more I can do with it now. – DrewAdams


I tried the newest icicles, because I’m interested in icicle-comint-search. I opened up a new shell buffer and tried it, but it gave a “no match for regexp” error. Seemingly this function only searches the comint inputs with a regexp in the current buffer. Since it’s a new buffer there’s no input yet in it. However in variable ‘comint-input-ring’ (which holds the previous inputs) there are lots of entries. Shouldn’t ‘icicle-comint-search’ use this variable instead of relying on regexp search?

As a side note I had to debug a bit to find out the actual error message, since icicles bailed out with the error (using Emacs version 21.1.4.): “Not enough arguments for format string”.

Debugger entered--Lisp error: (error "Not enough arguments for format string")
  format("No match for regexp `^[^#$%>\n]*[#$%>] *\\S-.*'")
  apply(format "No match for regexp `^[^#$%>\n]*[#$%>] *\\S-.*'")
  error("No match for regexp `^[^#$%>\n]*[#$%>] *\\S-.*'")
  (condition-case act-on-choice (funcall (quote icicle-execute-extended-command-1) 
       (completing-read ... obarray ... t nil ... nil nil)) (quit (when ... ...) nil)
     (error (when ... ...) nil (error ...)))
  (let* ((orig-buff ...) (orig-window ...) (last-cmd last-command) 
      (icicle-candidate-action-fn ...)) nil (condition-case act-on-choice 
        (funcall ... ...)
     (quit ... nil) (error ... nil ...)) nil)
  icicle-execute-extended-command()
  call-interactively(icicle-execute-extended-command)

TamasPatrovics

Hi Tamas; thanks for the bug report. I’ve just uploaded a new version of icicles-mac.el, which should fix the problem of not seeing the original error message. Let me know.

The answer to the real question you raise is that ‘comint-input-ring’ cannot be used in the definition of ‘icicle-comint-search’. That command is based on ‘icicle-search’, which, as you said, searches the buffer contents. I’ve defined a different command, ‘icicle-comint-command’, bound to ‘C-TAB’ in ‘comint-mode’, which should do what you expected. It’s not very sophisticated, but it does let you use the complete history, beyond the current session. Please try the latest version of icicles-cmd.el. – DrewAdams

Thanks! It’s working fine. – TamasPatrovics


I use icicle-incremental-completion-flag ‘always’ to always display a completions buffer, as I find it more effective than using icomplete. One problem is that when set to always, typing a single character will immediately try to complete. The following makes the completion behaviour nice:

  (setq icicle-incremental-completion-threshold 0)

--DamienElmes

No need for that now. I’ve fixed the bug. Thx – DrewAdams


Hi, while trying to use skeleton-read in a skeleton with icicles running, emacs gives me the following error:

if: Wrong number of arguments: #<subr read-from-minibuffer>, 8

Turning off icicles makes the error go away. You can replicate this by the following test code:

(define-skeleton test-skel
  "Test skeleton"
  ""
  > (skeleton-read "Input ?") \n
  )

The same error happens when I try to use customize-face. For both of these I am using the latest Emacs 22 from CVS, on Linux. – neverwinter.cs.wisc.edu

Thanks for the report. Should be OK now; please try the latest version. FYI – This comes from our trying to keep up with the bleeding edge. They introduced an extra (8th) argument for ‘read-from-minibuffer’ during Emacs 22 development, so I accommodated it. But they just removed the extra argument recently.

DrewAdams


  • To reproduce: select in menu ‘Icicles > Help’. Expected: help window. Happens: help window and error message

let: Wrong number of arguments: #[(string function data &optional help-echo) “` c bÅ !ÆÇ $)‡” [pos string function data help-echo search-forward help-xref-button 0] 5 605818], 2

Please let me know how I can provide more relevant information.(emacs 21.4.1)

  • Is there a way to report problems or ask questions other than editing this wiki, which I find not the most elegant way of communicating?
  • Is there a way to switch off the rectangular frame with the help text “S-TAB, TAB: list, C-h: help” which appears in minibuffer after I press e.g. C-h v? This rectangle both causes the minibuffer to change its height to about 1.5 lines height, and occupies more than half of the minibuffer so that the interesting information wraps into a second line after entering a few characters.

Thanks, Hans-Christoph

Thanks for your report.

  • Please download the latest version; this should now be fixed. FYI – Apparently function ‘help-insert-xref-button’ exists for Emacs 21.3, but with and entirely different (incompatible) signature from what it has in Emacs 22. (I hate it when they do that.)
  • You can report problems by email. Use ‘M-x customize-group icicles’ and click the link Bug Report.
  • To remove the prompt help, use ‘icicle-inhibit-reminder-prompt-flag’. See Icicles - Customization and General Tips; the third screenshot shows this.

DrewAdams

Thanks for your help. Works like a charm. H-C


I think I’ll like icicles apropos cycling very much, however, I can’t get it to work.

This is icicles.el update 17508 on Gnu emacs 21.4.1

To reproduce: Enter ‘C-h v line’ then press pgdown. Expected: apropos search starts.

Happens: Minibuffer opens, showing ‘Describe variable: ‘ followed by a rectangular area with some help information, followed by ‘inline’ where ‘line’ is underlined.

But: everything from ‘be variable:’ until the right end of the mininbuffer is highlighted yellow. Subsequent presses of pgdown give me ‘Text is readonly’ error message in minibuffer.

Further info: when I use cursor down/up (prefix matching) this works as expected, even ‘insert’ to switch back and forth to the completion buffer and navigate there, etc.

Even more info: apropos icicling after M-x works as expected. – Hans-Christoph

UPDATE: The problems I found went away after another exit and restart of emacs. Maybe it was an issue with some libraries only partially installed at first time. Sorry for bothering you. icicles seems to be a great product! – H-C

Thanks for following up with another test. I have no idea what caused that problem. It sounds like some other library interfered somehow. Thanks for trying Icicles. – DrewAdams


I’m finding the ‘icicle-find-file’ command very useful, but I’ve discovered another small problem with it. With the normal ‘find-file’, if I enter a directory name and hit ‘Ret’, that directory is opened in a dired buffer. If I do the same with ‘icicle-find-file’, nothing happens. --TobyCubitt

Good point. I didn’t notice this because I use Emacs 20 most of the time, and in Emacs 20 and Emacs 21 ‘find-file’ acts the same way as what you saw with ‘icicle-find-file’: it opens the file that you’re in (in another window, if you use ‘find-file-other-window’).

Please try the latest version. Closing this issue; feel free to reopen it if you see a problem with the fix.

FYI – It turns out that this was a high-level fix that a user could make: ‘icicle-find-file’ is defined with ‘icicle-define-file-command’, which uses ‘read-file-name’. Function ‘read-file-name’ uses the file that you’re in, not the ‘default-directory’ as the default value (what you get if you just hit ‘RET’). The fix was just to supply an explicit default value of ‘default-directory’ to ‘icicle-define-file-command’ in the definition of ‘icicle-find-file’. Standard Emacs command ‘find-file’ does not have this “problem” in Emacs 22 because it does not use ‘read-file-name’. – DrewAdams


Wow, thanks for ‘icicle-expand-input-to-common-match-flag’! 😊 I turned it on and it works great. There is an issue with file name completion though. I cannot reproduce it right now, but if it is turned on and you go down a directory hierarchy by completing directories then the completed directories are sometimes duplicated (lib/lib/) after completion (using apropos completion of course).

Please try to be more specific, or I doubt if I can help. Let me know what you did to get the symptom, starting with emacs -q --no-site-file. What Icicles options did you change, if any, besides ‘icicle-expand-input-to-common-match-flag’? What OS are you on? What version of Emacs?

I tried playing with directories and files, and tried setting ‘icicle-cycle-into-subdirs’ to ‘t’ (thinking perhaps that’s what you meant by “go down a directory hierarchy”), but I could not reproduce the problem. Were you cycling candidates ([next]) or just using ‘S-TAB’? I’ll need more info, and probably a clear recipe, if I’m to be able to help you on this. [P.S. I moved this to IciclesIssues.] Thx – DrewAdams

Ok, here’s a way to reproduce it starting with emacs -q --no-site-file and setting ‘icicle-expand-input-to-common-match-flag’ to t:

  • Change to the root directory: (find-file "/")
  • Try to open the directory /usr/local: find-file, type /usr/loc, press ‘S-TAB’

Instead of /usr/local/ the completion will be /local/local/ if ‘icicle-expand-input-to-common-match-flag’ is enabled.

Great – good bug report. Please try the latest version, and let me know if you find any problems with it. Thanks!DrewAdams

Yep. It seems to work fine now. Good job! 😊 I may post some further thoughts to icicles discussion about how I use icicles. Maybe you’ll find some of them interesting.

BTW, you should think about making downloading icicles easier, so that it’s not so cumbersome to get new releases. Currently I have to download all the libraries one by one. I’d like a single zip file instead containing all iciciles files which I could download and unzip. I assume you already have a script to post new releases to the wiki and doesn’t do it by hand (at least that’s what I would do). If so also creating a zip file and uploading it to the wiki should only be a couple of more lines in your release script.

Glad to hear things are working.


Hi! I’m trying to get my head around Icicles - Search-And-Replace. Is there some way to enable completion when specifiying the initial context-regexp, and especially when specifying the replacement? So far I’m getting by with M-. to insert word at point, and Pause to suspend the minibuffer temporarily.

Also, it would be nice to have an option to make the matches for the initial content-regexp be visible immediately as one types the regexp. Similar to how it works for incremental search.

Thanks, Johan Widén.

Hi Johan,

1. Completion is available when you enter the initial regexp (i.e., the context regexp). The completion is against the entries in ‘regexp-history’, and that history is updated to include any context regexp you enter.

2. Likewise, the same kind of completion is available for defining the replacement.

3. Currently there is no default value for #1 and #2. It sounds like you would want the word (for example) at point. I can think about doing that. I’m out this week, but when I get some time I’ll look into doing that.

4. I’m afraid that it would be impractical to provide incremental highlighting feedback as you type the context regexp. Instead, you have completion. Sorry. But at least you can see the contexts highlighted as soon as you hit ‘RET’ (though that can take some time).

HTH. I’m afraid it is about all I can offer. – DrewAdams

I should also have mentioned that you can do the following, to see what your context regexp will match as you type it. It provides a workaround for your requested incremental highlighting, while still allowing completion against past regexps.

C-S-r <type your regexp> S-TAB

That enters Icicles search and populates the minibuffer with that Isearch regexp for use as the Icicles search-context regexp. You can complete that input against the regexp history or just hit ‘RET’ to accept it.

See:

DrewAdams

OK: C-S-r achieves what I want for visual feedback.

I guess that completing against the regexp history might be enough for the initial regexp, but for the replacement I feel that it would be valuable to be able to complete against the words/symbols in the buffer (file) that I’m editing. – Johan Widén

1. Also, for the default, you can always use `M-.’ (repeating as needed) to insert text things at/near point into the minibuffer. See Icicles - Inserting Text from Cursor.

2. I have nevertheless now provided similar defaulting for the context regexp, so you can use ‘M-n’ instead of `M-.’ if you prefer – try the latest code.

3. Completion for reading the replacement string is against the history ‘icicle-search-replacement-history’, which is specific to this purpose (i.e., previously entered replacement strings). Defaulting is the same (things at point).

HTH – DrewAdams


Icicles is quite overwhelming, so I tried to use individual commands first instead of enabling icy-mode. When I tried icicle-occur (with icy-mode disabled) and pressed S-tab then I got the message: backtab is undefined. Prefix (tab) completion works.

Is it normal behavior? Or icicle-occur doesn’t work without enabling icy-mode? – Anonymous

1. The behavior offered by Icicles is encapsulated in a minor mode. When you turn off Icicle mode you are left with the vanilla Emacs behavior. That’s the point.

Thus, most of the Icicles commands do not work unless you are in Icicle mode. I could raise an error in case you call such a command outside Icicle mode, but I don’t bother to.

About the only commands that work outside Icicle mode are those that replace standard commands (see Icicles - Standard Functions Redefined), and in such cases they typically have the same name but with the prefix ‘icicle-’, and when you are not in Icicle mode they just do what the vanilla commands of the same name do.

2. Icicles can be overwhelming if you let yourself get overwhelmed easily. ;-) There is no reason not to take your time and learn it slowly. For the most part you can carry on as usual without noticing much difference from vanilla Emacs. For example, if you don’t use ‘S-TAB’ from the minibuffer then you get the usual, prefix completion matching. If you don’t use the cycling keys then, well, you get the same as vanilla Emacs: no cycling. ;-)

Yes, there are some things to be aware of, some differences you will notice that you can look up in the doc as you encounter them (as you did wrt ‘*Completions*’ display). But in general you can bite off bits of Icicles and digest them at your own speed.

I know that some people can get overwhelmed, in particular by the extensive doc. Some others don’t bother to read the doc at all. At least one user I know learned Icicles piece by piece very methodically, investigating every detail, and he studied the doc the same way. He took his time, however, and enjoyed it.

Learning Icicles should not be a pain, but it’s up to you, I think. You should be able to learn it progressively, and what you don’t know at any moment should not, in general, hurt you. ;-)

Do not hesitate to ask questions or mention problems you encounter, but the doc is also your friend (assuming you are comfortable with reading doc – some people are not, and that’s OK).

3. Icicles search (e.g. ‘icicle-occur’) is quite powerful, but it might not be the first thing to start with. It won’t hurt to start with it, but if you get discouraged and it seems too complex, turn to something simpler to start with. – DrewAdams

There is now an automatically generated zip archive of Icicles files from the Icicles repository on the GitHubMirror. See http://www.emacswiki.org/emacs/Icicles_-_Libraries#ZipFileDownload.

DrewAdams


Quick question. What is the equivalent key and feature for ‘M-r’ (search history by regexp) in Vanilla Emacs for Icicles? For smooth transition from vanilla Emacs, I may hope that this or equivalent feature is available by default key bindings… – golconda

See Icicles - History Enhancements, including Insert Previous Inputs. In particular:

In vanilla Emacs, the history lists are never shown as such; you can access previous inputs only one at a time, in order (with ‘M-p’). In vanilla Emacs, you can use a regexp to search the history list (via ‘M-r’ and ‘M-s’), but the regexp matching is not dynamic, and the first match found is the only one you get. In Icicle mode, ‘M-r’ and ‘M-s’ are not available for matching a history item — use ‘M-o’ instead.

I’ve experienced some difficulties in using icicles with cua. Huge thanks to Drew for helping me understand and work around this issue. Specificially, when the region is active in the minibuffer, and when cua-mode is enabled, self-inserting keys are bound to cua-replace-region, and the DEL key is bound to cua-delete-region. The region can become active when cycling through completions. This causes rather odd behaviour where you can only delete part of the text in the minibuffer, and cannot add new text to the minibuffer after cycling. A workaround is to set ‘icicle-point-position-in-candidate’ and ‘icicle-mark-position-in-candidate’ to the same value, so that the region doesn’t become active in the minibuffer. See also IciclesIssuesClosed#cua-mode for more discussion on cua-mode interactions.


hi Is it possible to create a directory using `C-c +’ on fly in other command than ‘C-x C-f’, for example using ‘C-x C-w’ or in dired rename ‘R’? Regards, JohnDoe974

Whenever it is possible it is documented in the doc string. It is possible for all Icicles commands that expect file-name input, in particular: ‘icicle-delete-file’, ‘icicle-dired’, ‘icicle-file’ (and similar), ‘icicle-recent-file’, ‘icicle-locate-file’, ‘icicle-file-list’, ‘icicle-directory-list’, ‘icicle-bookmark-a-file’, ‘icicle-find-file-tagged’.

There is no Icicles command bound to ‘C-x C-w’ or ‘R’ in Dired, so no for those. You could define Icicles commands for such things, however. – DrewAdams


pc-selection-mode redefines the standard movement keys (next-line → next-line-nomark) and Icicles fails to recognize this, so the movement keys are not rebound properly for minibuffer completion. – Anon

Your description is vague; I had to check the pc-select.el code. Library pc-select.el binds [down] in the current global keymap to ‘next-line-nomark’. It also rebinds all of the other arrow keys, their Shift versions, Shift-Control versions, and Shift-Meta versions, plus [next], [prior], and lots of other keys.

Do you expect the Icicles code to examine all of the global bindings made by other libraries such as pc-select.el, take them into account, and then restore them all when you leave Icicle mode? And account for all possible orders of loading those libraries?

That’s not the way the real world works. I’m afraid you’re going to have to become familiar with the various libraries you use, and deal with their various ways of binding keys.

The Icicles doc explains how Icicles deals with bindings. Armed with that knowledge, you can deal with your various other libraries as each requires – only you know what libraries you use and in what order.

In this case, I suspect that your problem might be solved by entering Icicle mode before PcSelectionMode. That will let Icicles pick up the standard Emacs global bindings, and Icicles doesn’t change global bindings, so it should not affect PcSelectionMode (except in the minibuffer).

If I’ve misunderstood your problem, then you’ll have to be more precise about it. As with all issues, please provide a clear recipe describing exactly what you do, starting from emacs -q --no-site-file. Mention also the versions of Emacs and libraries you use, and your platform. – DrewAdams

You’re right. This issue can be closed.


I can’t change keybindings on Emacs 21, because the icicle-mode-hook is not run by icicle-mode – Anon

Of course you can. Of course it is. Did you try it? What did you do? If you have a real problem, please try to express it clearly. – DrewAdams

I’m currently far away from my desktop, but if you take a look at icicles-mode.el you’ll see that (run-hooks 'icicle-mode-hook) is called from only that version of the function icicle-mode which is marked as Emacs 20 code. The Emacs 21+ version doesn’t have a run-hook invocation. Maybe I’m mistaken, but I can’t try it right now. Sorry for the incovenience if I’m wrong.

Emacs 21 and 22 have macro ‘define-minor-mode’, which defines the minor-mode function so that it runs the mode hook. IOW, code that uses ‘define-minor-mode’ does not need to explicitly run the hook. Try to use the hook. Closing this issue – let me know if you actually run into a problem. – DrewAdams

I should have thought of that. Silly me. 😊 The hook didn’t seem to run the first time I tried, so I checked the code and thought it was buggy. Thanks for the clarification.


I spent quite a few a time to find out which packages I need to download to try icicles and where to find them. Maybe it’s only me, but I couldn’t find any obvious download link on the main icicles page. You should consider putting a download link there if you want to make it easier for people to try icicles. Update: I finally downloaded it from the end of the nutshell page and it failed to load on emacs 21.4: Symbol’s function definition is void: minibuffer-indicate-depth-mode. Does it work only with Emacs 22? –- Anon

  • Sorry about ‘minibuffer-indicate-depth-mode’ – please download the latest version of icicles-mode.el. (FYI: minor mode ‘minibuffer-indicate-depth-mode’ has not yet been added to Emacs 22.)
  • I’ve added a link on page Icicles to the list of libraries. Hey, it’s here too now: Icicles - Libraries.
  • I will move this discussion to IciclesIssues.

DrewAdams


The icicle-find-file multi-command doesn’t seem to work properly. When I hit ‘C-RET’ on a completion, instead of opening the file, a new file with that name gets created in my home directory. Same thing with `C-!’ (only of course many new files get created instead of just one).

I assume the problem is that ‘icicle-find-file’ only passes the filename part of the string to find-file, not the full path, so find-file uses the default (home) directory, but I haven’t had a chance to look at the Lisp code yet.

Thanks for the report, Toby. Great bug. This was something fundamental, but which I would never see, because I use a standalone (separate) minibuffer frame. This is why it’s good to have users!
I think it’s fixed, but since the fix cut deep there is always the risk that other things will now be broken. Let me know. – DrewAdams
BTW, I didn’t see (on MS Windows) the same symptoms you described. No files were created in any directory. Instead, what I saw before the fix (?) was this:
      1. Creation of buffers visiting the files, as expected.
      2. But no switching to any of the buffers.
The reason for #2 was that ‘switch-to-buffer’ was trying to switch to the buffer in the minibuffer window (which is a no-no). The problem was that ‘C-RET’ is executed from the minibuffer, and so, therefore, was the function passed to ‘icicle-define-file-command’.
I fixed the problem that I saw, I believe. I hope this has something to do with what you saw and that your problem is also fixed. Let me know – DrewAdams

You’re probably right about it just creating buffers, not files. But for me, the buffers were associated with new files in my home directory, and were therefore empty. It definitely didn’t create buffers visiting the correct files. That’s why I thought maybe only the filename without the path was being passed to ‘find-file’.

I’ll try the new update and report back.

PS: Sorry for deleting that other reply last time! Completely unintentional.

--TobyCubitt

Bad news. The latest version (22.0) has exactly the same problem as the old one: ‘C-Ret’ or `C-!’ from ‘icicles-find-file’ open buffers associated with files in my home directory rather than buffers visiting the files they should.

Somewhere between the original version and this latest one, it sort of half worked. (Unfortunately I can’t be more specific since I don’t have that version lying around anymore. I seem to remember that ‘icicles-find-file’ worked most of the time but prefix cycling was broken.)

This is running on the multi-tty CVS branch under Linux, BTW.

--TobyCubitt

Please try the latest version. I think I found and fixed the problem. But please let me know. Thanks!DrewAdams

Looks good to me! If I find anything whilst playing with it I’ll post it here. If nothing crops up, you can probably mark this as resolved. --TobyCubitt

I moved the code that controls the directory into the definition of macro ‘icicle-define-file-command’, so you can once again simply provide a function such as ‘find-file’ as the argument to the macro. That is, you don’t need to control the directory within the action function; the macro takes care of that.
Thanks again for this bug report. – DrewAdams

Recent changes in icicles (I guess it’s icicle-init-value-flag) broke gnus-sum:gnus-articles-to-read. When selecting group gnus asks “How many articles from gnu.emacs.gnus (default 232):”, if you press <enter> it raise error:

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  string-match("^[ 	]*$" nil)
  byte-code("....
  gnus-articles-to-read("gnu.emacs.gnus" nil)
  gnus-select-newsgroup("gnu.emacs.gnus" nil nil)
  gnus-summary-read-group-1("gnu.emacs.gnus" nil t nil nil nil)
  gnus-summary-read-group("gnu.emacs.gnus" nil t nil nil nil nil)
  gnus-group-read-group(nil t)
  gnus-group-select-group(nil)
  call-interactively(gnus-group-select-group)

I believe it should not be a big issue, I just missing something. Thanks. – Andrey Zhdanov

Hi Andrey. Thanks for the report (and thanks for trying Icicles). Please mention the icicles.el Update # (in the file header) or the Last-Updated date (also in the header).

I introduced a bug in early February, which I suspect caused your problem. This is fixed (I hope) in the latest version (e.g. Update #: 14097, Last-Updated: Fri Feb 10 00:43:10 2006). If you do not have that version, please try it and let me know if you still have the problem.

If you still have a problem, please use `M-x load-file icicles.el’ before provoking the error – that will use the source library, not the byte-compiled library, which provides more info in the backtrace. (I do not use gnus, so the gnus part of a backtrace won’t help me, but once an Icicles function is called, that helps me locate the problem.

Thanks – DrewAdams

Have done some debuging in gnus-sum.el Error happens here:

(input
  (read-string
   (format
    "How many articles from %s (%s %d): "
    (gnus-limit-string
     (gnus-group-decoded-name gnus-newsgroup-name)
     35)
    (if initial "max" "default")
    number)
   (if initial
      (cons (number-to-string initial)
     0))))) ;;; <<< reads minifub, just pressing <enter> 
   (if (string-match "^[ \t]*$" input) number input))) 
;;; Wrong type argument: stringp, nil

lines # 5344-5356. With icicles loaded input is nil, without - “”. I’m using cvs emacs on win32/msvc. Latest icicles 14097, and it was not byte-compiled, it was actually gnus’s byte-code. Tested with empty .emacs. Thanks – AndreyZ

Thanks. Should be OK now. Please try the latest version (2006-02-11). – DrewAdams

Just tested version #14115. Still have error. Here is the short test code for reproducing:

(defun testcase()
 (let ((input
  (read-string 
    (format "How many (1000): ")))) ;;; press <enter> 
   (if (string-match "^[ \t]*$" input) 1111 input) "OK" ))
(testcase)

Returns “OK” when icicles not loaded. That is how gnus expects it to work on default entry (which means nothing entered, just C-m). – AndreyZ

Thanks again! There were two bugs. Should be fixed now (he said again with trepidation). Sorry to make you work so hard. – DrewAdams

Great! Works fine in latest version. Thanks again! – AndreyZ


File name autocompletion is broken. I’m using emacs 21.4.1 with icicles 19/08/2005. icicle-cycle-into-subdirs-flag value is nil. For example when I try to autocomplete /site/e<tab> in the directory structure:

  /site/
    /emacs/
    ...

the already completed prefix changes to /etc. Also /site/em<tab> doesn’t find any completion candidate. Etc. It seems as icicles is always trying to autocomplete from root. Setting icicle-cycle-into-subdirs-flag to t doesn’t help but instead brings a new set of quirks into scene. The same applies to old-read-file-name, which works well as read-file-name when icicles is not loaded, but as soon as I require icicles becomes broken (with the behaviour described above) as old-read-file-name. Carlos

Thanks for the bug report. And thanks for trying Icicles.

I found and fixed a major bug in file-name completion when using non-MS Windows platforms. In effect, I was using a hack that works only for Windows, and the hack was, in any case, unnecessary.

I’m guessing you will have no problem now. Please let me know, otherwise. Thanks. – DrewAdams, 2005-09-01

I just downloaded tonight (2005-09-16) a copy of icicle and all the code on which it depends, yet I’m seeing the same problem that Carlos was reporting above. Also, when I do C-x C-f, I’m presented with the curious default of `(~/ . 2)’. What might be going on? I’m on Mac OS 10.4 and running emacs 21.3.50 (a copy from 2004-11-17). --JesseAlama.

Bummer. Sounds like a serious bug. You will have to help, if this is to be solved – I cannot test on Mac OS, and I don’t have 21.3.50 from 2004-11-17. I’ve tested this on Windows (Emacs versions 20.7, 21.3.1, 22) and on Linux (actually, Linux files and directories accessed remotely from Windows with ange ftp).

1. Can you please give me the exact steps you use to encounter the bug.

2. Can you try using the debugger to follow the execution path a bit. Load `icicles.el’ (not `icicles.elc’) before debugging. Debug whatever command you are using – ‘icicle-prefix-complete’, ‘icicle-next-prefix-candidate’, etc. via ‘debug-on-entry’. As you step through the debugger in the relevant area, test variables ‘default-directory’ and ‘icicles-default-directory’ occasionally.

3. You might also try an older version of `icicles.el’, prior to the fix that treats directories the same as files, for cycling. It could be that that fix reintroduced Carlos’s problem. That is, try a version that is earlier than Revision 52 and later than Revision 32. The revisions are here: http://www.emacswiki.org/cgi-bin/emacs?action=history;id=icicles.el.

If I get some more info on this, I’ll follow up. For now, there’s not much I can do with the info I have. You’ll have to do some of the checking, on Mac OS. It might be something simple, but I have no way of knowing now. I’ve just verified that the current version works on Linux files and directories (via ange ftp from Windows). There’s no reason this shouldn’t be fixed for Mac users too!

If anyone else can help by checking the behavior on MacOS (and directly on Linux), I would appreciate it, as well.

Thanks – DrewAdams, 2005-09-19

[BTW – You mention that you downloaded “all the code on which [Icicles] depends”. icicles.el does not depend on any other code. The ‘require’s in icicles.el are all soft requires, which means that you do not really need them. You need only standard library `cl.el’, and that is needed only for byte-compiling.]

I had the problem with emacs-21.4 on a Linux system (Gentoo) using icicles.el revision 67. If TAB completing on the with only one completion that is complete then the directory path disappears and I am left with only the filename minus the directory name. I fixed by the following change to icicles.el:

diff -p /home/myname/emacs/icicles-67.el /home/mjreed/emacs/icicles.el
*** /home/myname/emacs/icicles-67.el	2005-10-05 13:57:23.000000000 +0100
--- /home/myname/emacs/icicles.el	2005-10-05 15:06:24.000000000 +0100
*************** Otherwise, return the list of completion
*** 2331,2340 ****
              (setq icicle-last-completion-candidate
                    (if (and (icicle-file-name-input-p) insert-default-directory)
                        (expand-file-name
!                        (if (and (> (length icicle-current-input) 0)
!                                 (eq ?/ (aref icicle-current-input 0)))
!                            (concat "/" (car icicle-completion-candidates))
!                          (car icicle-completion-candidates))
                         (icicle-file-name-directory-w-default icicle-current-input))
                      (car icicle-completion-candidates))))
             (when (icicle-file-directory-p icicle-last-completion-candidate)
--- 2331,2337 ----
              (setq icicle-last-completion-candidate
                    (if (and (icicle-file-name-input-p) insert-default-directory)
                        (expand-file-name
!                        (car icicle-completion-candidates)
                         (icicle-file-name-directory-w-default icicle-current-input))
                      (car icicle-completion-candidates))))
             (when (icicle-file-directory-p icicle-last-completion-candidate)

I am not quite sure about the purpose of the (if…) that I have deleted. It would seem to remove all the path apart from the last name component of the filename if the name starts with a “/”. It seems on Linux for an example file “~/home/myname/incomplete_now_complete”: that the first time I TAB complete I have “~/path/incomplete” completed to “/home/myname/path/incomplete_now_complete”. Then hitting TAB again the leading “/” is picked up and the if statment becomes true so that I loose “/home/myname/path” and get (concat “/” “incomplete_now_complete”). Hope this helps…. – MartinReed , 2005-10-05

Thanks for the report, Martin.

Your report helped. Yes, that is vestigial cruft code that was there before my general fix to this problem. I had removed 95% of it, but I had left this part because I wasn’t sure whether it was still needed, and things seemed to work OK (on MS Windows) without it.

I’ve now removed that cruft. The same silly test existed in both functions ‘icicle-prefix-complete’ and ‘icicle-apropos-complete-1’. Things seem to still work OK on Windows now (nothing broken), so let’s give it a try. I’d be grateful if someone would test this on Linux, to see if the problem still exists.

BTW – I don’t know what you mean by revision 67 of Icicles. There is a ‘Version’ number in the header, which is 22.0, which I don’t change and which indicates more or less the version of Emacs current when I introduced the library (it doesn’t mean much). And there is an ‘Update’ number in the header, which truly indicates the revision of Icicles (my library header2.el updates this number each time I save the file after changing it).

Thanks again! – Drew

Yes new “revision” works fine in Linux (Gentoo), Emacs 21.4.

Drew: you said “I don’t know what you mean by revision 67 of Icicles”. I was just following your revision description in your earlier response and using the “revisions” listed there as you said :” 3. You might also try an older version of `icicles.el’, prior to the fix that treats directories the same as files, for cycling. It could be that that fix reintroduced Carlos’s problem. That is, try a version that is earlier than Revision 52 and later than Revision 32. The revisions are here: http://www.emacswiki.org/cgi-bin/emacs?action=history;id=icicles.el.” (you might want to remove this last comment and your “BTW”;-) )

BTW great library, I am starting to get into the other “icicle” family members as well - I wish they were packaged up with most of the common Emacs disributions….

Great! Glad it finally seems to work on Linux.

Ah, sorry, I see what you mean about “revision” – you meant Emacs-Wiki revision. In general, the ‘Update’ number in the file itself is the best way to identify a given version.

I’m happy to see some people are trying out Icicles. Let me know of any ideas that come to you, at IciclesDiscussion. – DrewAdams


icicles/icomplete+ Regexp search in history does not work - [No Match] is shown.

GNU Emacs 22.0.50.1 (i686-pc-cygwin, X toolkit, Xaw3d scroll bars) and GNU Emacs 22.0.50.1 (i386-msvc-nt5.1.2600) of 2005-09-11

How to reproduce: - .emacs with only icomplete+, icicles;

 M-x ve <ret> - ok, prints version;
 M-x ph <ret> - ok, prints phases-of-moon;
 M-x M-r mo <ret> - completes to phases-of-moon;
 <ret> - shows "M-x phases-of-moon [No Match]" in minibuffer;

The same way “M-x M-r” behaves when delsel.el loaded, but at least there is default delsel.el in emacs/lisp/ which looks ok. Sorry for putting it here, there is no discussion for icomplete+/delsel.

- Andrey - susuman_at_hotmail_dot_com

Thanks for the report. Please try the latest versions of ;icicles.el and icomplete+.el.

The problem was in fact more important that what you described. It was not just that [No match] was displayed (inappropriately). In addition, you could not use <ret> to re-execute the command! The reason was that I was resetting ‘minibuffer-completion-table’ to ‘nil’, so no input was being recognized as a valid completion.

La Petite Histoire: Long, long ago (long before Icicles), I added code to icomplete+.el that resets the ‘minibuffer-completion-table’ to ‘nil’. This was to prevent icompletion from displaying irrelevant stuff during input by ‘read-string’, ‘read-from-minibuffer’ etc., since completion (and icompletion) is not pertinent during those kinds of minibuffer input.

Similarly, in the predecessor to Icicles (elect-mbuf.el), my definitions of ‘exit-minibuffer’ and (the predecessor of) ‘icicle-abort-minibuffer-input’ also reset ‘minibuffer-completion-table’ to ‘nil’, for the same reason.

I’ve now removed that legacy code designed to prevent inappropriate icompletion, and that fixes the problem you report. I suspect that Emacs has long ago fixed the icomplete display bugs that this code tried to work around, but I’m not sure. If not, I might need to revisit this later, to try some other way to prevent the inappropriate icomplete display.

Note that if you used the previous version of icomplete+.el and you also use any of my libraries that use ‘read-string’, ‘read-from-minibuffer’, or ‘read-no-blanks-input’, you will need to re-‘byte-compile’ those libraries.

Finally, I don’t understand your last paragraph. What is the connection with delsel? Are you making a distinction there between my version of delsel (delsel.el) and the standard version in emacs/lisp/? Sorry, I don’t get your point here. Let me know if there is still a problem.

Thanks – DrewAdams.

Thanks! That’s exactly what I meant - could not execute command after completion.

Concerning yours delsel, it turns out to be the same icomplete+ issue, you have fixed. delsel loads frame-cmds and frame-cmds loads icomlete+. I ran tests with clean dot-emacs but forget to clean site-lisp, so when entering pc-selection-mode, I had the same problem with minibuffer history. Renaming yours delsel.el helped and I thought it was a source of a problem too.

Now everything works fine.


icicles - Update #: 7258 from Fri Sep 16 18:22:08 2005, GNU Emacs 21.3.1 - CCRMA Fedora 3. Loading gives debugger message: "Invalid modifier in string". – edgar-rft@web.de - 2005-09-23

Two hours later: it’s “\C-!” that causes the error - but why ? - I have no idea - “!” and “\M-!” work, “\S-!” and “\C-!” cause an “Invalid modifier in string” error - edgar

Another day later: [?\C-!] works! - edgar - 2005-09-24

There was indeed a bug. It seems that: (1) the string “\C-!” does not work in Emacs; (2) “\C-!” gives no error message in Emacs 20, but it acts the same as “\C-a”. (However, it did seem to me to work OK in Emacs 20 – go figure!) I’ve changed the binding to [(control ?!)] which works on all Emacs versions. Thanks. – DrewAdams


[from edgar-rft@web.de] – icicles.el Update #: 6195 from Tue Sep 06 21:22:05 2005 - GNU Emacs 21.3.1. CCRMA Fedora 3:

[S-tab] doesn’t work at all. Counter-check: GNU Emacs 21.3 on Win2000 (no_Cygwin): [S-tab] works. Fedora 3 solution: Type “C-h k” then press [S-tab]. Now in the minibuffer appears: “<S-iso-lefttab> is undefined”. [S-tab] on Fedora 3 is called [S-iso-lefttab] (this may vary in other countries or on other systems). Now in icicles.el I have replaced all occurrences of [S-tab] with [S-iso-lefttab] and it works. (Maybe needs a costomisation variable).

Again, thanks for the feedback. It looks like you found a solution for `[S-tab]’ on Fedora. I’m not sure it’s worth changing the code to include `[S-iso-lefttab]’, but it might be worth a comment or doc-string addition. – DrewAdams

I finally got around to adding the binding `[S-iso-lefttab]’. Let me know if there is any problem. – DrewAdams

icicles - Update #: 7298 - from Mon Sep 26 13:57:25 2005 - GNU Emacs 21.3.1 on CCRMA Fedora 3

I’m sorry but: S-iso-lefttab works only if you bind/unbind it in icicle-bind-completion-keys and icicle-restore-completion-keys, too - (I assume you cannot test this and therefore haven’t noticed). Nevertheless thank you, I never had the idea of double keybindings. With icicles I learn every day something new - edgar-rft@web.de - 2005-09-27

Duh…right. This will be fixed in the next version. In the meantime, you can add the fix to your copy. Thanks. – DrewAdams

No problem - I alredy have done this - there is no need for a special update - thanks - edgar

Fixed in latest version. – DrewAdams


[from edgar-rft@web.de] – icicles.el Update #: 6195 from Tue Sep 06 21:22:05 2005 - GNU Emacs 21.3.1. CCRMA Fedora 3:

[S-tab] doesn’t work at all. Counter-check: GNU Emacs 21.3 on Win2000 (no_Cygwin): [S-tab] works. Fedora 3 solution: Type “C-h k” then press [S-tab]. Now in the minibuffer appears: “<S-iso-lefttab> is undefined”. [S-tab] on Fedora 3 is called [S-iso-lefttab] (this may vary in other countries or on other systems). Now in icicles.el I have replaced all occurrences of [S-tab] with [S-iso-lefttab] and it works. (Maybe needs a costomisation variable).

Again, thanks for the feedback. It looks like you found a solution for `[S-tab]’ on Fedora. I’m not sure it’s worth changing the code to include `[S-iso-lefttab]’, but it might be worth a comment or doc-string addition. – DrewAdams

I finally got around to adding the binding `[S-iso-lefttab]’. Let me know if there is any problem. – DrewAdams

icicles - Update #: 7298 - from Mon Sep 26 13:57:25 2005 - GNU Emacs 21.3.1 on CCRMA Fedora 3

I’m sorry but: S-iso-lefttab works only if you bind/unbind it in icicle-bind-completion-keys and icicle-restore-completion-keys, too - (I assume you cannot test this and therefore haven’t noticed). Nevertheless thank you, I never had the idea of double keybindings. With icicles I learn every day something new - edgar-rft@web.de - 2005-09-27

Duh…right. This will be fixed in the next version. In the meantime, you can add the fix to your copy. Thanks. – DrewAdams

No problem - I alredy have done this - there is no need for a special update - thanks - edgar

Fixed in latest version. – DrewAdams


Hi !

First of all: I like this “cycle everything the same way” idea very much but nevertheless I have a problem: If I try to open a file with C-x C-f and ‘icicle-cycle-into-subdirs-flag’ is ‘nil’ I have no subdirectory name completion. If ‘icicle-cycle-into-subdirs-flag’ is non-’nil’ icicle starts to descend into the subdirs immediately as soon as it meets the first one with no return (it cycles in the deepest subdir forever). IMHO this is no meaningful behaviour. May it not be better to cycle in the current dir with name completion to all files and subdirs (like emacs or bash standard behaviour) ? Or is there a trick to work around ?

Thanks to Drew Adams for icicle.el

edgar-rft@web.de

Good point, and thanks for your feedback. I don’t have time to look into a solution now, but will try to get to it sooner or later. I agree that this would be a more user-friendly behavior. – DrewAdams

Thanks, it’s not too hurry, I have an “icicle-mode on/off”-key and can work around this. – edgar-rft@web.de

This should be fixed now, and other aspects of file and directory name treatment should also be improved. As there is a lot to test for this fix, it’s possible that other bugs have been introduced. Please let me know if you have any problems. Thanks - DrewAdams

Thanks a lot - that looks great! This is much more than I had expected. - I was extremely busy the last few days so I haven’t tested too much, I will give you more details the next few days. - BTW: I have a Mac (but not connected at the moment) I will try to reproduce Jesse’s problems but can’t promise too much because I still have to work with OS X 10.3.9 - My video card drivers refuse to work with OS X 10.4 😟 - edgar-rft@web.de


icicles.el Update #: 6195 from Tue Sep 06 21:22:05 2005 - GNU Emacs 21.3.1

GNU Emacs 21.3.1 - General bug on all tested systems (minor priority): If I switch with [insert] into the “Completion” buffer the first four entries cannot be selected. In the “Completion” buffer cursor movement is only possible between the fifth (bug) and the last entry where icicles stops and doesn’t cycle at all (maybe normal - it’s not important to me). Cycling all entries in the minibuffer works fine.

General comment: apropos-help-completion-cycling with doc-strings is great !!! - edgar-rft@web.de

Again, thanks for the feedback. I don’t have much time right now, but it turned out that your ‘*Completions*’ bug was a simple one to find and fix.

a. In ‘*Completions*’, you should have seen this at the top of the buffer:

  Click <mouse-2> on a completion to select it.  (C-h: help)
  Possible completions are:
  <first entry here>                 <second entry here>
  <third entry here>                 <fourth entry here>

but you were seeing only this:

  Possible completions are:
  <first entry here>                 <second entry here>
  <third entry here>                 <fourth entry here>

The arrow keys that let you navigate among entries do not let you access the first three lines, which are heading text. Since your heading text was missing two lines, you couldn’t access the first two lines of entries.

This problem – not being able to access the first two lines of ‘*Completions*’ entries usig the arrow keys – arose from my trying to provide a workable ‘completion-setup-function’ for different Emacs versions. I still use Emacs 20, mostly, but I test with 20 and 22 – I don’t test with 21. Function ‘completion-setup-function’ changed between 20 and 22, and I assumed it changed between 20 and 21 – so, I used the 22 version for 21 also.

Luckily, I have an old Emacs 21.3.1 I can test with, so I was able to find the problem. Please download the latest icicles.el and see if the problem is fixed.

b. It is “normal” (i.e., by design) that the `[down]’ and `[right]’ arrows do not move beyond the last entry (do not cycle back to the first entry). When you are navigating in ‘*Completions*’, you are not cycling completion candidates. – DrewAdams

I just fixed b. Using ‘right’/‘left’ (or ‘TAB’/‘S-TAB’) and ‘down’/‘up’ to navigate in ‘*Completions*’ now wraps around. – DrewAdams


Some good and some bad news: The “Completion” buffer now lets me navigate all entries (and also the highlighting works now) but as soon as I select one of that entries there appears a “let*: Symbol’s function definition is void: minubufferp” error.

But before you get completely nuts: This is not so important to me. Cycling in the minibuffer works fine and everything else I have written to this page for the reason that people who have similar problems may have some hints how to work around. I do not expect icicles to be fixed until tomorrow morning. Emacs is a developers environment and not a “Push-the-Button” application. I have started to read the icicles source code and as soon as I have an idea how to help I will tell you.

Don’t be worried: it’s not my interest to spread hacked versions of icicles and I surely will not do so but we just try to use Emacs as a developers environment for “Nyquist” (based on XLisp), a language for music composition and audio processing and icicles could be very useful as a kind of “unified users interface and help center” for all the involved lisp languages and dialects (cycling different lisp interpreters). 😊

Multi-Lisp-Hacking (as I’m used to say) … - thanks a lot - edgar-rft@web.de

Should be fixed now – please try latest version. Same problem as yesterday: Emacs 20 code, not Emacs 22 code, is used for Emacs 21.3.1. In some places it’s one; in other places it’s the other. It’s hard to keep track (though I should have guessed that this one was also Emacs 20). – DrewAdams

Confirmation: - Fedora 3 - GNU Emacs 21.3.1 - icicles Update #: 6552 - Bug is fixed now - thank you - edgar-rft@web.de


$ emacs -q M-x load-file RET ~/icicles.el RET ;; The one with the “offending” code above commented C-x C-f ~ RET ;; Just open some directory Place cursor on a file or directory R (rename)

Generates the following backtrace:

 Debugger entered--Lisp error: (wrong-number-of-arguments #<subr read-file-name> 6)
  (old-read-file-name icicle-prompt dir default-filename
    require-match initial-input predicate)
  (setq result (old-read-file-name icicle-prompt dir default-filename 
        require-match initial-input predicate))
  (let ((minibuffer-prompt-properties ...))
    (setq result (old-read-file-name icicle-prompt dir default-filename 
          require-match initial-input predicate)))
  (if (boundp (quote minibuffer-prompt-properties))
    (let (...) (setq result ...))
      (setq result (old-read-file-name icicle-prompt dir default-filename 
            require-match initial-input)))
  (cond ((> ... ...)
         (setq icicle-prompt prompt) (if ... ... ...)) 
        (t (setq icicle-prompt ...) (if ... ... ...)))
  (let (result) (cond (... ... ...) (t ... ...))
    (when (and require-match ...) (remove-windows-on "*Completions*")) result)
  read-file-name("Rename album_pics to: " "/home/mathias/" 
     "/home/mathias/album_pics")
  apply(read-file-name ("Rename album_pics to: " 
     "/home/mathias/" "/home/mathias/album_pics"))
  dired-mark-pop-up(nil move ("album_pics") read-file-name "Rename album_pics to: " 
     "/home/mathias/" "/home/mathias/album_pics")
  dired-mark-read-file-name("Rename %s to: " "/home/mathias/" move nil 
     ("album_pics") "/home/mathias/album_pics")
  dired-do-create-files(move dired-rename-file "Move" nil t "Rename")
  dired-do-rename(nil)
* call-interactively(dired-do-rename)

Great bug description – thanks. This is what comes from trying to create a library that works for multiple Emacs versions. And there is a coding lesson (moral) here…

I generally test in Emacs 20 and 22 (CVS, though not the latest), but not in Emacs 21 (pre 21.3.50). Knowing that ‘read-file-name’ takes 6 args (max) in Emacs 22 (CVS), but 5 args (max) in Emacs 20, I used this:

 (if (boundp 'minibuffer-prompt-properties) ; If Emacs 22+, use predicate arg.
     (setq result (old-read-file-name icicle-prompt dir default-filename
                                      require-match initial-input predicate))
   (setq result (old-read-file-name icicle-prompt dir default-filename
                                    require-match initial-input)))

That works OK in Emacs 20 and 22, and testing with ‘boundp’ is generally preferable to tests involving the version. (Also, in the actual code, I need to test for `(boundp 'minibuffer-prompt-properties)’ anyway.)

However, the ‘boundp’ was not specific to the code it protects (I cheated, figuring someone like MaDa would put me wise if there was a problem).

Here is the right way to do it:

 (condition-case nil                ; If Emacs 22+, use predicate arg.
   (setq result (old-read-file-name icicle-prompt dir default-filename
                                    require-match initial-input predicate))
  (wrong-number-of-arguments
    (setq result (old-read-file-name icicle-prompt dir default-filename
                                     require-match initial-input))))

Please download the new version and give it a try. Let me know if you there any problems. Thanks – DrewAdams


Icicles causes this error when I start Emacs in a terminal/console:

error: no such color: “unspecified-bg”

Only commenting out the appropriate lines helps:

 ;;  (require 'icicles)
 ;;  (require 'icicles-menu)
 ;;  (icicle-mode 1)        

– henry atting

Icicles isn’t intended for console mode. The problems for console mode are colors and key bindings. Console mode doesn’t have bindings such as ‘S-TAB’ and ‘C-RET’. If you rebind all commands bound to such unavailable bindings, and you use only available colors, you might be OK, but that’s a lot of bindings! It really isn’t intended for use in a console. icicles-menu.el might work in console mode, however; it is not really related to Icicles, in spite of the name. – DrewAdams

FWIW, I’ve become aware that some Icicles users do in fact use it in console mode, and some of those use it together with ViperMode. – DrewAdams


I am using Icicles with emacs 24.0.50 (a pretty recent built right from the bzr repository) on GNU/Linux x86_64. So far Icicles is working, but I notices one issue: File name completion in shell work does not work. Entering ./ and pressing TAB does not open the Completions buffer. When icicles is disabled, everything works fine. – tor-exit-router42-readme.formlessnetworking.net

Emacs 24 is not yet released, hence not supported by Icicles. I have nevertheless tracked some Emacs 24 changes and updated Icicles accordingly. But not very much in this regard.

Here is one workaround, after you download the latest Icicles files:

  (add-hook 'comint-mode-hook
            (lambda () (setq comint-dynamic-complete-functions
                        '(comint-replace-by-expanded-history
                          comint-dynamic-complete-filename))))

That gives you essentially the Emacs 23 Icicles completion for this.

If you do not want Icicles to get involved with such completion, then you can instead customize ‘icicle-comint-dynamic-complete-replacements’ to ‘nil’ and customize ‘icicle-functions-to-redefine’ to remove the comint functions that are there by default. HTH – DrewAdams


Previous: IciclesIssuesIciclesIciclesIssuesOpenIciclesIssuesStale

CategoryCompletion