This page is a record of stale issues reported by users of library icicles.el (Icicles), including bugs. These are issues that the reporting users did not follow up on – never heard back from them. Could mean that the problem is not a problem; could mean that they gave up ;-).
These issues were reported long ago, but followup info was lacking. I leave them here in case someone else experiences a similar problem. If you do, please follow up with a new bug report. Thanks.
For readability, please separate each issue thread with
‘----’ (horizontal line), and introduce each entry within a thread with `
Better yet, use this to separate threads (puts space before and after the horizontal line):
</pre> ---- <pre>
With the latest icicles files updated via icicles-install there is a problem with the GNU emacs 23.1.97 final release candidate for 23.2 that doesn’t occur for 23.1.
(add-to-list 'load-path "...") (require 'icicles-install) (require 'icicles)
debugger entered--Lisp error: (wrong-type-argument listp 2C-command)
Adding the following lines fixes the problem
(add-to-list 'load-path "...") (require 'icicles-install) (require 'two-column) (require 'icicles)
Sorry – wiki formatting is perplexing. – [[Gen.Sec.?]]
I cannot reproduce the problem - please provide more info (e.g.
*Messages* output that might be pertinent,
*Backtrace* buffer, precise recipe to follow,…). If you use the debugger, be sure to load the source files (
I tried with
emacs -Q using only the source files (
*.el), and I tried again using the
*.elc files byte-compiled using the same Emacs 23-1-97 prerelease. It’s best to test using
emacs -Q and loading only the source files (
*.elc). If you do test using byte-compiled files, be sure they are freshly compiled.)
Also, be sure you have all the latest Icicles files. I’m not responsible for icicles-install.el, so I cannot tell you whether it always does the right thing. I assume it does, but to be sure you might want to compare the dates or the
Update numbers in the file headers of each file downloaded with those currently posted on the wiki at the ElispArea. Sorry for your trouble. – DrewAdams
I have a problem with apropos completion, as described in IciclesIssuesClosed, but I do not quite understand the discussion there. I would appreciate any help or a suggestion of where to look for help, and I can move this question to the thread in the Closed Issues page.
I put the Icicles libraries on my load path, add
(require 'icicles) to my file ~/.emacs, start emacs, and execute
M-x icy-mode; The echo area shows “Turning ON Icicle mode…done”. Then I type
M-x buffer S-Tab, and the echo area shows
<backtab> is undefined. I use Emacs 22.2.1. File icicles-opt.el says:
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.
I did not find a way to customize “backtab” to the value “([S-tab] [S-iso-lefttab])”. Also, putting
(setq icicle-generic-S-tab-keys '([S-tab] [S-iso-lefttab])) in my init files did not help. – PhilipGanchev?
First, please make sure you have the latest Icicles files.
‘backtab’ is not used as the default value, and
‘icicle-generic-S-tab-keys’ no longer exists (it is called
The comment you quote is out of date (I’ve just changed it).
‘backtab’ is not used as the default value because of what is mentioned in the other comment just before that one – see Emacs bug #1281.
The value you were trying to get is in fact the default value. It means that
[S-iso-lefttab] will be bound for Icicles apropos completion. Things should work OK if you get the latest files. If not, let me know. Thx – DrewAdams
(add-to-list 'load-path "path/to/icicles") (load-library "icicles") Debugger entered--Lisp error: (void-variable icicle-mode-map)
I get an error when I try to load the icicles library.
1. I am using a recent build of Emacs 184.108.40.206 on Mac OS X 10.5
2. The error only happens if I have byte-compiled the icicles code. If there are nothing but .el files in the directory it is fine.
3. If I evaluate (load-library “icicles”) again it works fine and the package is loaded.
4. (Side note: the discussion on IciclesIswitchb does not apply to my environment. The only way I’ve been able to get iswitchb functionality working is to use all of (iswitchb-mode), (require ‘icicles), (iswitchb-default-keybindings), (require ‘icicles-iswitchb).)
Perhaps 23.1 isn’t supported yet? – [[rmolinari?]]
Sorry for your trouble. Thanks for your report, but I will need more info.
1. I do support the release (23.1), but I do not officially support the CVS development code, which is what you are using (220.127.116.11) – it is too much of a moving target. Nevertheless, I know that there are Icicles users who do use the latest CVS Emacs with no problem.
2. Make sure that all of the Icicles files you have are the latest versions. Be sure to start with
emacs -Q for a bug recipe.
3. With byte-compiled code, make sure that you load the source files before compiling. It is at least important to load icicles-mac.el before byte-compiling the other files, since it contains macros that they use.
4. If you can get hold of an official release (e.g. Emacs 23.1 or 22.3), see if you can reproduce the problem with it. That might save time if you cannot. It’s possible that there is a change in the CVS code that affects this. But I doubt it. Usually, problems of this kind come from compiling and loading sequencing.
5. I’m afraid you will need to do some debugging to figure out what is happening. The load order in icicles.el should be correct. You can try turning on
‘debug-on-error’. You can try loading each of the byte-compiled files, in turn (in the order given in icicles.el. You can try loading all of the source files except for a single byte-compiled file, in turn.
6. Wrt IswitchB, I’m afraid I can’t help. I don’t use it, myself. I sanity-tested it briefly with Icicles long ago, but I don’t retest the combination. All I know is what others have written on page IciclesIswitchb. Feel free to update that page if you have additional info. – DrewAdams
Hi Drew. Thanks for the quick reply. Loading icicles before byte-compiling didn’t help so there must be something squirrelly in my setup. I don’t have time to investigate more carefully right now but will try to find time later in the week. Thanks for a great product! – [[rmolinari?]]
OK, let me know what you find out. Even more details about what you did helps. – DrewAdams
After loading the library (which works) the below error is reported (Symbol’s value as variable is void: <!DOCTYPE). Then I cannot turn on icicles (no command icy-mode available)
Loading /home/energieautark/administration/templates/EmacsConfigEtc/lispLibraries/icicles/icicles.el (source)… load-with-code-conversion: Symbol’s value as variable is void: <!DOCTYPE Making completion list… – Thomas
I suspect that you somehow downloaded the HTML code for the EmacsWiki page that presents a library, rather than the library (EmacsLisp code) itself. Or perhaps the download was somehow corrupted. There is no
DOCTYPE text in any of the Icicles libraries. Please check the files that you downloaded, to see that they are in fact Lisp code. You can also
DOCTYPE to ensure that it is not present in any library.
To download a file from its wiki page (e.g. [[icicles-cmd.el?]]), right-click the
Download link and choose
Save As from your browser menu (or equivalent, depending on your browser). Alternatively, you can bulk-download all of the files using one of the methods described here: Bulk Icicles Download.
However, it seems weird that things work at all, if you are trying to load an HTML page as Lisp code. ;-) And you say “it works”, in general. So I will need to know exactly how it does not work.
If a corrupted Lisp file is not in fact the problem, then please provide a precise recipe to reproduce the problem, starting with
emacs -Q (no init file). If you like, use
‘M-x icicle-send-bug-report’, which will include additional info (your Emacs version etc.). And please make sure you use the latest Icicles files, since they are what I will use to debug.
FWIW, the only places in the Icicles code that a message
Making completion list... is displayed are in commands
‘icicle-bbdb-complete-name’. So if you’re seeing that message, then you must somehow be invoking one of those commands. You can try
‘M-x debug-on-entry icicle-dabbrev-completion’ etc. and step through the debugger with
‘c’, to see what is happening. If you use the debugger, be sure to explicitly load the source files (
.elc), at least [[icicles-cmd.el?]], which defines those commands. Thx – DrewAdams
this doesn’t compile:
(icicle-define-command icicle-command-abbrev-command "Read command name, then read its arguments and call command. Read input, then call `icicle-execute-extended-command-1' to act on it." ; Doc string icicle-execute-extended-command-1 ; Function to perform the action (format "Command abbreviated%s%s: " ; `completing-read' arguments (cond ((and icicle-current-input (not (string= "" icicle-current-input))) (format " `%s'" icicle-current-input)) (icicle-candidate-nb (format " `%s'" (elt icicle-completion-candidates icicle-candidate-nb))) (t "")) (if current-prefix-arg (format " (prefix %d)" (prefix-numeric-value current-prefix-arg)) "")) icicle-commands-for-abbrev nil t nil 'extended-command-history nil nil (;; Bindings (use-file-dialog nil) (last-command last-command) (icicle-add-proxy-candidates-flag nil) new-last-cmd) nil nil (setq this-command new-last-cmd) t)
error-> icicles-cmd.el:1036:1:Error: Wrong number of arguments: #[(command doc-string function prompt table &optional predicate require-match initial-input hist def inherit-input-method bindings first-sexp undo-sexp last-sexp) "\306 \307 \3109\205 ...
thanks for this great package – [[84-73-33-50.dclient.hispeed.ch?]]
I suspect you do not have the latest version of icicles-mac.el, or perhaps you did not recompile the other libraries after loading the latest version of icicles-mac.el. That is a library of macros, including
‘icicle-define-command’, so it must be loaded before you byte-compile the libraries that use its macros. I recently added another optional argument to
‘icicle-define-command’, so if the latest icicles-mac.el is not loaded then the byte compiler will complain here (
‘icicle-command-abbrev-command’ is defined using that new optional arg).
When using Icicles-mode together with nxml-mode for editing (docbook-)xml-files, sometimes (not always!) when using nxml-element-completion my buffer gets screwed. This happens only when icicles is active.
What I usually do is partly type some element name, for example ‘em’ (if I want to insert the ‘emphasis’-docbook element) then hit C-RET for element completion. The minibuffer pops up with possible completions for ‘em’, in this case ‘email’ and ‘emphasis’. Then I hit [next] to select ‘emphasis’ (this is where icicle-functionality comes in) and then RET again to finish element completion.
What I would expect to happen is that the element ‘<emphasis>’ gets inserted at point. But what happens when Icicles is active is that suddenly point is somewhere else in the buffer (usually several lines above where it was before calling the minibuffer). That way, the newly created element gets inserted at a wrong position in the buffer.
Also, sometimes when using the minibuffer in the way described above, a selection becomes active (though there was no selection active before hitting C-RET for element-completion) and again the buffer contents get screwed when inserting the selected element from the minibuffer.
None of this happens when I switch off Icicles-mode.
Nevertheless, I love icicles-mode and would like to continue using it especially in conjunction with nXML-mode.
PS: I’m using Emacs 22 with nXML-mode, all icicles-files are up to date (20060308) – ClausKlingberg?
‘C-RET’a nxml binding in the minibuffer? In Icicles,
‘C-RET’in the minibuffer is something entirely different – it does not complete your input. If
‘C-RET’is an nxml binding, then you must be loading nxml after Icicles, and it tramples the Icicles minibuffer bindings. If both libraries create or modify minibuffer bindings, then you’ll have to sort out which ones you want to keep as is and which you want to change. See Icicles - Customizing Key Bindings for how to change Icicles bindings.
‘M-x customize-group icicles’, then click button Send Bug Report. – DrewAdams
Meanwhile, the issue is still happening, though nxml-mode/nxhtml-mode underwent some serious re-factoring since last year (nxhmlt more than nxml, though). I’m not too optimistic about debugging this successfully (at least my tries failed so far).
The bug only surfaces in distinct situations, like when the completion (minibuffer-)window becomes large enough that re-centering in my xml-buffer has to occur after selecting a completion-text. If there are only a few completion-candidates in the minibuffer and my current editing happened in the center or above of the screen, all is fine: no re-centering necessary, no bug!
But as soon as I’m typing toward the bottom of the xml-buffer and the completion-candidates can’t fit completely in one line, then, upon selecting one candidate, the minibuffer gets closed, re-centering appears (like someone hit C-l for me) which displaces the cursor to some position above to where I was typing. And the completion-text gets inserted there, not were I was typing.
It almost seems like one forgot a “save-excursion” which, if I’m not mistaken, should prevent just this. Though I understand it’s probably not that easy.
While the debugger window is visible, this kind of re-centering never appears, which is what makes it so hard to trace down.
Not sure if my description is comprehensible at all, perhaps I should create a screencast about it :-} – ClausKlingberg?
‘RET’? Also, I’ll need to know if this is during strict or lax completion (see Icicles - Nutshell View#MultiCommands). The command used to accept a completion is different in each case.
‘M-x debug-on-entry minibuffer-complete-and-exit’and
‘M-x debug-on-entry exit-minibuffer’. If you don’t enter the debugger during your problem, then try M-x debug-on-entry choose-completion-string’ instead (or
‘mouse-choose-completion’, if you’re choosing with the mouse). To cancel debugging all functions, do
‘M-x cancel-debug-on-entry RET’.
Using the ordinary ‘debug’ command I wasn’t able to reproduce the “cursor-jumping” issue (that’s what I’m calling this behaviour now). Every time the debug-window pops up, the window-setup is changed and I can’t reproduce it. So, I switched to ‘edebug’ and finally it’s possible to watch things happen while debugging.
Playing around with edebug I found a mistake I made in my previous error-description: The cursor in my nxml-buffer, where I initiated tag-completion jumps before any interactive selection in the mini-buffer is made, not after selecting anything. Only as a result of this cursor-jumping the selected completion-text gets then inserted at the wrong cursor-position in the xml-buffer after completion (pressing RET) is done. Sorry for the confusion.
So far, I’m still not able to pinpoint the exact location where this happens, but I’ve drilled it down to hopefully close after “icicle-minibuffer-setup”. Icicles then probably calls “rng-complete-qname-function” (for a second time) to collect the completion candidates to display in the minibuffer. And just when it populates the minibuffer, it’s window widens and boom the cursor-position in the xml-buffer jumps upwards to make room and is never restored.
This is probably not very helpful for you so far, I just wanted you to know that I’m working on it. I still have problems to fully understand program flow, since constructs like “run-hooks(minibuffer-setup-hook)” give me a headache (What methods are called here and at what point is this determined?). I also get confused to which version of “(old-)completing-read” gets called at what time. Anyway, as soon as I find out more, I’ll post it here. – ClausKlingberg?
Thanks for plugging away at this, Claus. We’ll get it figured out eventually.
‘completing-read’, when you are in Icicle mode, does some stuff and then it calls
‘old-completing-read’, which is the original, vanilla-Emacs version of
Do mean after
‘icicle-minibuffer-setup’ is finished or after it is entered? I’ll assume the former, for now. I had a suspicion that it might be the initialization in
‘icicle-pre-minibuffer-buffer’ (e.g. it picked up the wrong buffer), but that is used only in
‘icicle-switch-to/from-minibuffer’, which is used only when you explicitly hit the
‘pause’ key. You didn’t do that, did you?
You didn’t add anything to any Icicles hooks or minibuffer hooks, did you? How about
‘post-command-hook’? It’s a good idea to know about that sort of thing, before looking further. – DrewAdams
Another update: to answer your questions first - the issue appears without (i.e. before) me hitting any key while the minibuffer is active. What I found out is that, actually, it seems like the cursor jumping happens when “minibuffer-completion-help” is called initially to display the possible completion candidates.
Now, nxml-mode adds
minibuffer-completion-help to the
minibuffer-setup-hook in it’s function
rng-complete-before-point (in rng-util.el):
[...] (defun rng-complete-before-point (start table prompt &optional predicate hist) [...] (setq completion (let ((saved-minibuffer-setup-hook (default-value 'minibuffer-setup-hook))) (add-hook 'minibuffer-setup-hook 'minibuffer-completion-help t) (unwind-protect (completing-read prompt table predicate nil orig hist) (setq-default minibuffer-setup-hook saved-minibuffer-setup-hook)))) (delete-region start (point)) (insert completion) completion)))) [...]
If I just comment out the line with
'minibuffer-completion-help being added, the cursor jumping is no longer reproducible!
Sure, that means no completion candidates are displayed in the minibuffer initially, but I can view them by hitting <S-TAB> if I need to (without the issue reappearing). This already comes close to an almost perfect fix for me, I don’t feel like losing much.
That doesn’t however solve the problems root cause, does it? Or isn’t nxml-mode expected to add minibuffer-setup-hooks by itself? Also, the question remains why adding
'minibuffer-completion-help by nxml leads to this issue only in conjunction with icicles.
I’m not sure how much deeper I should dig into this. If this report didn’t give you any clues on what might be going wrong, perhaps I’ll investigate a bit further when time allows. – ClausKlingberg?
Thanks, Claus. Unfortunately, I still don’t have a clue. Something is causing the cursor position to change – no doubt something in
‘minibuffer-setup-hook’, probably something in
‘icicle-minibuffer-setup’. But I can’t see what. Some things you might try, to discover more about what’s happening:
‘rng-complete-before-point’, examining the value of
‘point’at different locations. Probably
‘point’will be incorrect at the very beginning, but it’s worth checking. Debugging will also show if an error is encountered during
‘t’argument from the
‘add-hook’, so the help is run sooner than
‘icicle-minibuffer-setup’, and see what happens.
I tried adding
‘minibuffer-completion-help’ at the end of
‘minibuffer-setup-hook’ (without using nxhtml), and I didn’t see any problem.
Sorry I don’t have a good idea here. Somehow, you need to find where
(point) gets changed. You’ve discovered that the cursor gets moved somewhere in
‘rng-complete-before-point’, but are the values
‘point’ correct when
‘rng-complete-before-point’ is entered?
You might try either adding some
‘message’ debugging or using
‘debug-on-entry’ to see if you can figure it out. – DrewAdams
I wanted to remove the binding of
‘icicle-abort-minibuffer-input’ in the global keymap, because my understanding of elisp is rather limited and I end up in a debug situation rather often. I didn’t see how to do this with the techniques in Icicles - Customizing Key Bindings, so I just added
(define-key icicle-mode-map [?\C-\]] nil)
‘icicle-mode-hook’ function. – ErikPostma?
This sounds like a bug of some sort – you should not end up in the debugger with
‘icicle-abort-minibuffer’. It’s important that
‘icicle-abort-minibuffer’ work correctly; it’s generally not a good idea to not use it.
Could you please try without your workaround, and post the debugger (Backtrace) stack. You can either post it here or, better, send it as a bug report:
‘M-x icicle-send-bug-report’. – DrewAdams
Any news on this? – DrewAdams
icicles - Update #: 7298 - from Mon Sep 26 13:57:25 2005 - GNU Emacs 21.3.1 on CCRMA Fedora 3
Using dired for opening files with C-x C-f is a very nice idea but the problem is that as soon as I enter a subdirectory and dired takes control I have no minibuffer messages any longer. But keyboard control and minibuffer messages are important because we develope audio software for blinds and it’s very difficult for the speech software to keep track if the TextCursor jumps between the buffers all the time. At the moment the only way is still simply to switch off icicles if I want to enter a subdirectory.
Please do not mis-understand: I do not consider this as a ‘bug’ but nevertheless the question: do you see a way how to work around this ? The strange thing: in this case icicles seems to be a worsification against the emacs out-of-the-box behavior and one of the reasons to use icicles originally was to use icicles’ minibuffer cycling instead the overloaded dired display (with speech software it takes several minutes to find the right directory).
but beside all my nagging - thank you for your never ending work on icicles - firstname.lastname@example.org - 2005-09-27
P.S.: Nobody expects that you change icicles now to become a speech software interface but please tell me what you think about this.
Again, you will need to give me the exact steps you use to reproduce the problem. I don’t know what you mean by “enter a subdirectory”, or “dired takes control”, and so on. What it the setting of option
Just write down exactly what you do, starting with
emacs -q, and exactly what symptoms you see (or don’t see but expect to see).
I don’t see how Icicles would suppress logging of messages to buffer
‘*Messages*’, but I can see that it might suppress the display of some messages in the echo area (where the minibuffer is). Also, are you speaking of display of messages or echoing of keystrokes? I will need more info, to understand just what the problem is.
If your blind users rely on messages, perhaps you should provide them with an easy way to retrieve them from buffer
‘*Messages*’, in any case. Have you thought of that? Perhaps just displaying
‘*Messages*’ in a separate window would provide some benefit.
BTW, it didn’t occur to me that Icicles might be of special use to blind people. Thanks for the insight. I will keep it in mind for the future. – DrewAdams
Please excuse, this (and the next two) were only a short summary and no way a detailed bug report - I first wanted to know what you think about this - I have to do lots of testing of my own code this week and will give you better and more detailed bug descriptions - edgar
icicles - Update #: 7298 - from Mon Sep 26 13:57:25 2005 - GNU Emacs 21.3.1 on CCRMA Fedora 3
Also, if possible, icicles should please load
cl-macs in the beginning and not during file display - the speech software always reads to me unneccessary icicles error messages between the file names - or is it dired which loads
cl-macs ? - email@example.com - 2005-09-27
Please be clearer about the behavior you experience. Just what happens?
When you say that
cl-macs is loaded during file display, that would seem to indicate that perhaps the mode of the displayed file requires
cl-macs. Have you tried with different kinds of files, and with
emacs -q? If you suspect that dired might be loading
cl-macs, try using dired before you use Icicles – do you get the same behavior?
Icicles should not load
cl-macs at all, if you use the byte-compiled file
icicles.elc. If it does, we want to determine what part of Icicles is implicated.
If you report exactly the steps you use and the effects you observe, perhaps I can help you figure out what is causing your problem. As a temporary workaround, if you feel that Icicles is loading
cl-macs, just load
cl-macs yourself, before loading
icicles.elc. – DrewAdams
icicles - Update #: 7298 - from Mon Sep 26 13:57:25 2005 - GNU Emacs 21.3.1 on CCRMA Fedora 3
Another thing: In a ‘Completions’ buffer, if I click with ‘mouse 2’ on any completion item I only get an ‘Text is read only’ message (with the cursor keys and ‘Return’ it works) - firstname.lastname@example.org - 2005-09-27
I cannot reproduce this. Please give me the exact steps you use. And please check using
emacs -q (loading icicles.el). Perhaps another library you use is removing the mouse-2 binding (replacing it by the normal
When I try it, either with the cursor in the minibuffer (default) or with the cursor in
‘*Completions*’ (after using
[insert]), I get the expected behavior.
After turning on Icicle mode, do
‘C-h v completion-list-mode-map’ – what is the binding for
‘mouse-2’ in this keymap? It should be
‘mouse-choose-completion’. What happens if you do not use Icicles at all? Does
‘mouse-2’ work correctly in
‘*Completions*’? – DrewAdams