headers
Tobias C. Rittweiler | 5 Apr 2007 14:37
Picon

RFC for completion behaviour


Hi Slime-hackers,

Two issues related to how completion should behave:

  a) As of now, completing on "asdf::" or "asdf::foo" means that it's
     tried to find any (or the respective) symbols within 
     #<PACKAGE "ASDF"> that is _accessible_.

     However, this includes all those symbols that are inherited from
     other packages, including :CL, as most packages include it.

     If you're looking for a symbol that you know is _internal_ to some
     package, you're forced to search through (possibly) quite a mess.

     So what do you think, to change the completion code to only try to
     match against symbols _internal_ to #<PACKAGE "ASDF"> in the above
     case?

     The downside is that if you've got a package :A that uses some
     internal packages :B and :C for internal code structure purpose,
     you won't be able to find the symbols in these internal packages.

     So if people want the new bevahiour, I'd implement it in a way that
     is has to be explicitely enabled by setting some global value.

     What's your opinion on this?

  b) Slime's standard completion function `SLIME-COMPLETE-SYMBOL*'
     (i.e. the one that is used at the REPL, for instance) completes
(Continue reading)

Permalink | Reply | 13 comments |
headers
Tobias C. Rittweiler | 5 Apr 2007 14:41
Picon

Re: RFC for completion behaviour

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

>      So what do you think, to change the completion code to only try to
>      match against symbols _internal_ to #<PACKAGE "ASDF"> in the above
>      case?
>      
>      The downside is that if you've got a package :A that uses some
>      internal packages :B and :C for internal code structure purpose,
>      you won't be able to find the symbols in these internal packages.

It will still find the symbols if they're exported from :A, of course.

  -T.
Permalink | Reply | 0 comments |
headers
Edi Weitz | 5 Apr 2007 14:56
Picon
Favicon

Re: RFC for completion behaviour

On Thu, 05 Apr 2007 14:37:22 +0200, "Tobias C. Rittweiler" <tcr <at> freebits.de> wrote:

>   b) Slime's standard completion function `SLIME-COMPLETE-SYMBOL*'
>   (i.e. the one that is used at the REPL, for instance) completes
>   "asdf:*Com" to "asdf:*COMPILE-FILE--BEHAVIOUR*", where point is at
>   the end of the completion.
>
>   (As opposed to `SLIME-SIMPLE-COMPLETE-SYMBOL', which would
>   complete it to "asdf:*COMPILE-FILE-".)
>
>   Traditionally, the point has been set to the place between the two
>   dashes ("asdf:*COMPILE-FILE-|-BEHAVIOUR*", where "|" is supposed
>   to mean the cursor.) It doesn't anymore, rendering that kind of
>   completion pretty much b0rked.
>
>   I'd like to restore the traditional behaviour. Comments?

You have my vote.

Edi.
Permalink | Reply | 5 comments |
headers
Jeffrey Cunningham | 5 Apr 2007 18:06
Picon
Favicon

Re: *sldb sbcl/0* infinite loop?

Jeffrey Cunningham wrote:
> Hi,
> 
> I have been running into a problem off and on for several weeks that 
> seems to come from an interaction between slime and SBCL resulting in an 
> infinite loop requiring me to killall sbcl to stop it. Until now I 
> haven't been able to isolate it to a simple case. Here's one:
> 
> * I start up emacs (21.4.1)
> * I start up M-x slime (2007-03-29).
> * In the slime-repl I type the bogus command 'lt' <enter>.
> 
> The speaker starts beeping and slime and emacs are utterly hung. I have 
> to kill sbcl which releases emacs to keyboard commands.
> 
> When I hit C-x b a window opens up at the bottom of emacs which shows 
> the following:
> 
> iswitch 
> {imagelib.lisp,*scratch*,*Messages*,*Compile-Log*,*slime-events*,*sldb 
> sbcl/0*,*sldb sbcl/0*<2>,*sldb sbcl/0*<3>,...
> where the number inside the braces keeps incrementing forever 
> <4>,...,<5>... etc.
> 
> I will attach a screen capture in case it isn't clear. I can't navigate 
> to that window and copy it.
> 
> The steps I've taken to isolate the problem are to update sbcl to todays 
> version (1.0.4) compiled from source (from 1.0.3 - both act the same 
> way), and to remove my .sbclrc file.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Chris Dean | 5 Apr 2007 19:54
Favicon
Gravatar

Re: RFC for completion behaviour


My comments are:

"Tobias C. Rittweiler" <tcr <at> freebits.de> writes:
>   a) [...] So what do you think, to change the completion code to only try to
>      match against symbols _internal_ to #<PACKAGE "ASDF"> in the above
>      case?

+1   (That is, yes seems like a great idea.)

>   b) [...] I'd like to restore the traditional behaviour. Comments?

+0   (I don't feel strongly about it, but I'm okay with the change.)

Cheers,
Chris Dean
Permalink | Reply | 0 comments |
headers
Madhu | 6 Apr 2007 04:32

Re: RFC for completion behaviour

* Edi Weitz <u7isr0yk9.fsf <at> agharta.de> :

| On Thu, 05 Apr 2007 14:37:22 +0200, "Tobias C. Rittweiler" <tcr <at> freebits.de> wrote:
|
|>   b) Slime's standard completion function `SLIME-COMPLETE-SYMBOL*'
|>   (i.e. the one that is used at the REPL, for instance) completes
|>   "asdf:*Com" to "asdf:*COMPILE-FILE--BEHAVIOUR*", where point is at
|>   the end of the completion.
|>
|>   (As opposed to `SLIME-SIMPLE-COMPLETE-SYMBOL', which would
|>   complete it to "asdf:*COMPILE-FILE-".)
|>
|>   Traditionally, the point has been set to the place between the two
|>   dashes ("asdf:*COMPILE-FILE-|-BEHAVIOUR*", where "|" is supposed
|>   to mean the cursor.) It doesn't anymore, rendering that kind of
|>   completion pretty much b0rked.
|>
|>   I'd like to restore the traditional behaviour. Comments?
|
| You have my vote.

Except this would completely bork choosing a completion interactively
from the "*Completions*" buffer, which is pretty fundamental to any
completion interface.

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

The patch was sent in the message with the following headers:
(Continue reading)

Permalink | Reply | 4 comments |
headers
Tobias C. Rittweiler | 6 Apr 2007 11:26
Picon

Re: RFC for completion behaviour


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 <at> 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
(Continue reading)

Permalink | Reply | 3 comments |
headers
Nikodemus Siivola | 6 Apr 2007 11:29
Gravatar

Re: RFC for completion behaviour

Tobias C. Rittweiler wrote:
 > Hi Slime-hackers,
 >
 > Two issues related to how completion should behave:
 >
 >   a) As of now, completing on "asdf::" or "asdf::foo" means that it's
...
 >      What's your opinion on this?

Yes please!

 >   b) Slime's standard completion function `SLIME-COMPLETE-SYMBOL*'
...
 >      I'd like to restore the traditional behaviour. Comments?

Fine with me.

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.

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.

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

Permalink | Reply | 3 comments |
headers
Tobias C. Rittweiler | 6 Apr 2007 11:52
Picon

Re: RFC for completion behaviour

Nikodemus Siivola <nikodemus <at> 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.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Nikodemus Siivola | 6 Apr 2007 12:07
Gravatar

Re: Re: RFC for completion behaviour

Tobias C. Rittweiler wrote:

 > 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.

Yes, sorry about the confusion.

 >> 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.

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

 > The problem is that this doesn't restore the previous window layout
 > (just as `Esc Esc Esc' wouldn't.)

C-c left == winner-undo would, but that also leaves arrow keys out
in the cold...

 >> Finally, we don't seem to have a way to select a completion and
 >> insert just the completion anymore.
 >
 > Just press TAB.
(Continue reading)

Permalink | Reply | 1 comment |

Gmane