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.