Thanks Madhu for commenting on this! I've been told on IRC that there was some issues around this, and thus wanted asked here before doing work unnecessarily. I'm a bit disappointed that such things don't seem to get properly documented in the ChangeLog in the fist place. Madhu <enometh@meer.net> writes:

This was debated to death and I provided a patch to support both behaviours. I'd rather you commmit a version of that

Summary for those who are too lazy to look at the thread themselves: Completion alternatives are provided within the *Completions* buffer, clicking on such a completion choice (or switching to the buffer and pressing RET) invokes `CHOOSE-COMPLETION' that inserts the chosen completion _up to point_. If point is set to the place of first mismatch v asdf:*compile-file-|-behaviour* ^ clicking on such a choice will result in the wrong asdf:*compile-file-failure-behaviour*-behaviour* while typing `f TAB' (asdf:*compile-file-f[TAB]-behaviour*) would invoke the Slime specific completion function again which can handle this case gracefully and it would be correctly completed to asdf:*compile-file-failure-behaviour*

The patch was sent in the message with the following headers:

Introducing yet another global variable which basically does nothing else than determining between "Pissing-off Edi" or "Pissing-off Madhu" is not the way to go. :) Let's stop doing that; Slime's kludgy enough already. I can perceive two solutions: a) We can fix `CHOOSE-COMPLETION' to DTRT by defining an appropriate function and hooking up `CHOOSE-COMPLETION-STRING-FUNCTIONS'. b) Let's drop that kind of behaviour alltogether. I initially thought the behaviour of inserting a common suffix as well as a common prefix was kind of cool, but then, if you think about it, it doesn't provide any real ergonomic advantage: asdf:*com TAB will be expanded to asdf:*compile-file--behaviour* offering as possible completions asdf:*compile-file-failure-behaviour* asdf:*compile-file-warnings-behaviour* So you must press `f' or `w' to decide on it _anyway_; it doesn't matter if the initial completion simply expanded to asdf:*compile-file- since a common suffix means that it _will_ be automatically completed anyway! Comments? -T.

"Tobias C. Rittweiler" <tcr@freebits.de> writes:

[...]

I've been bitten by a bug in the older SBCL version I use that prevented me from seeing what a shenanigan I had straying in my code; here's a better patch: 2007-04-28 Tobias C. Rittweiler <INSERT-EMAIL-HERE> Removed support for completing to the longest compound pre- and suffix with the default completion method (C-c TAB, or just TAB on the REPL), because it has been causing trouble all the time, but didn't offer any real advantage besides niftiness. E.g.: previous behaviour: asdf:*com TAB => asdf:*compile-file--behaviour* now simply: asdf:*com TAB => asdf:*compile-file- For discussing on this subject, please see the mail with message-id <87y7l53lch.fsf@freebits.de> that was posted to slime-devel 2007-04-06, or alternatively: http://common-lisp.net/pipermail/slime-devel/2007-April/006087.html * swank.lisp (make-compound-prefix-matcher): New function. Abstracted from COMPOUND-PREFIX-MATCH. (compound-prefix-match): Use MAKE-COMPOUND-PREFIX-MATCHER. (compound-prefix-match/ci/underscores): Removed. (completions): Slight docstring modification, also added an examplary use case; use LONGEST-COMMON-PREFIX instead of LONGEST-COMPLETION. (completions-for-character): Use LONGEST-COMMON-PREFIX, and MAKE-COMPOUND-PREFIX-MATCHER. (longest-completion): Removed. Not needed anymore. (tokenize-completion): Likewise. (untokenize-completion): Likewise. (transpose-lists): Likewise. (longest-completion/underscores): Likewise. (tokenize-completion/underscores): Likewise. (untokenize-completion/underscores): Likewise.

Nikodemus Siivola <nikodemus@random-state.net> writes:

Also, an additional request: for the q-key to about a completion attempt I need to enter the completion buffer. Ok, I see how this makes sense. But if I allow my reflexes to hit Esc Esc Esc to cancel the completion attempt the completion buffer is hidden but the arrow-keys in my previous buffer remain attached to the now-hidden completion buffer.

To avoid any confusion, please be aware that you're talking about Fuzzy Completion here! Only there the arrow keys are rebound. And that sounds like a bug (missing UNWIND-PROTECT?); I'm gonna look at it.

I suggest that a single Esc in the orginal buffer should work just like a q in the completion buffer, or that there was another single keystroke to dismiss the completion buffer.

Alternatively to `Esc Esc Esc', you can savely use `C-x 1', an already (underneath) existing completion buffer doesn't infere with subsequent completions. The problem is that this doesn't restore the previous window layout (just as `Esc Esc Esc' wouldn't.)

Finally, we don't seem to have a way to select a completion and insert just the completion anymore.

Just press TAB. -T.

I've been informed that `C-g' is bound in the original buffer to an appropriate abort function. Nikodemus Siivola <nikodemus@random-state.net> writes:

Currently C-x 1 has the same issue as Esc*3, but I assume that is another bug. ;-)

True. It can, however, be made DTRT with Esc*3 quite easily. And with winner-undo, too. (Basically, everything that got an appropriate hook.) It could theoretically be made to work for `C-x 1', too -- that is every time the *Fuzzy Completions* buffer becomes non-human viewable -- but I'm not sure it's worth the trouble. -T.