Re: [slime-devel] Closing *Completions* buffer
Tiago Maduro-Dias <tcmd@rnl.ist.utl.pt> writes:
Hope this helps!
This is quite nice. Thanks for the patch. It's in CVS now. Helmut.
Hello, This new feature is really nice, but wouldn't it be ever better if the *Completions* buffer was closed when the completion is finally done ? I think it is more functional, the problem is that I am not good enough at Emacs programming to do it myself. I'll give a try though ... Best regards, Camille On 20 avr. 04, at 23:56, Helmut Eller wrote:
Tiago Maduro-Dias <tcmd@rnl.ist.utl.pt> writes:
Hope this helps!
This is quite nice. Thanks for the patch. It's in CVS now.
Helmut.
_______________________________________________ slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
On Wed, 2004-04-21 at 00:58, Camille Troillard wrote:
This new feature is really nice, but wouldn't it be ever better if the *Completions* buffer was closed when the completion is finally done ? I think it is more functional, the problem is that I am not good enough at Emacs programming to do it myself. I'll give a try though ...
I suppose it makes sense... The attached patch should take care of that in a pretty straight forward (read hackish) manner. Seems to be working though. It keeps the previous space related behaviour and adds the slime-close-buffer to the sole completion cases (that's what you were referring to, right?). I also removed a redundant test in the slime-close-buffer function... Again, hope this can be useful in some way :). Tiago. -- "I conjecture that there is no good algorithm for the traveling salesman problem. My reasons are the same as for any mathematical cojecture: (1) It is a legitimate mathematical possiblity, and (2) I do not know." --Jack Edmonds, 1966
Hi again, Apparently the problem with the current version of slime-complete-restore-window-configuration is somehow related to the use of bury-buffer. Instead of the hackish patch I sent earlier this version makes use of the present structure but calls the slime-close-buffer function instead, which basically does the same as the previous code but makes use of kill-buffer. Another important issue is the use of the slime-completions-buffer-name variable instead of the hard coded "*Completions*". Sorry for not paying closer attention to the code before sending the suggested patches to the list. Tiago. -- "I conjecture that there is no good algorithm for the traveling salesman problem. My reasons are the same as for any mathematical cojecture: (1) It is a legitimate mathematical possiblity, and (2) I do not know." --Jack Edmonds, 1966
Hi Slimy People, Could you please consider merging this patch? Thank you! Camille On 21 avr. 04, at 01:19, Tiago Maduro-Dias wrote:
On Wed, 2004-04-21 at 00:58, Camille Troillard wrote:
This new feature is really nice, but wouldn't it be ever better if the *Completions* buffer was closed when the completion is finally done ? I think it is more functional, the problem is that I am not good enough at Emacs programming to do it myself. I'll give a try though ...
I suppose it makes sense... The attached patch should take care of that in a pretty straight forward (read hackish) manner. Seems to be working though. It keeps the previous space related behaviour and adds the slime-close-buffer to the sole completion cases (that's what you were referring to, right?).
I also removed a redundant test in the slime-close-buffer function...
Again, hope this can be useful in some way :).
Tiago.
Camille Troillard <tuscland@mac.com> writes:
Hello,
This new feature is really nice, but wouldn't it be ever better if the *Completions* buffer was closed when the completion is finally done ? I think it is more functional, the problem is that I am not good enough at Emacs programming to do it myself. I'll give a try though ...
There is code to do this (was already there before this patch). Unfortunately it is not so easy to detect when a "completion is finally done". Currently the buffer is closed after a completion, when the user types one of the chars "()\"'`,# \r\n:" after. We also wait for the next possibility when the user inserts a self-inserting char, completes again or a hits backspace. We give up if the user does something else, like switching to another buffer. If you have a better or simpler idea, please speak up :) Helmut.
Helmut Eller wrote:
Currently the buffer is closed after a completion, when the user types one of the chars "()\"'`,# \r\n:" after. We also wait for the next possibility when the user inserts a self-inserting char, completes again or a hits backspace. We give up if the user does something else, like switching to another buffer.
If you have a better or simpler idea, please speak up :)
The patch Tiago sent just adds the little tweak I was suggesting. Thanks ! Camille
On Tue, Apr 20, 2004 at 11:56:21PM +0200, Helmut Eller wrote:
Tiago Maduro-Dias <tcmd@rnl.ist.utl.pt> writes:
Hope this helps!
This is quite nice. Thanks for the patch. It's in CVS now.
This doesn't seem to work quite right for me. Here's how. 1. Start emacs. I have one frame with one window that's *scratch*. 2. M-x slime. (Mine happens to be OpenMCL.) 3. Slime loads. Now I have two windows, *scratch* on top, and *slime-repl[1]* on bottom, selected. 4. I only want the REPL, so I C-x 1, making slime-repl take the whole screen. 5. I type "(symb<TAB>". It completes to "(symbol", and the completions pop up in a window at the bottom of the screen. 6. I want symbol-macrolet, so I type "-m<TAB>". It completes symbol-macrolet. But my window is still split; *scratch* has taken the place of *Completions*. I banished *scratch* above, I don't want to see it again. I find this more annoying than just having the completions stay up, since at least they have some bearing on my Lisp work. I think it should restore the window configuration that was there before the completions popped up, unless windows manipulation commands were run in the interim, in which cast the user would be annoyed when whatever he did disappeared. Unfortunately I have no clue how to do this. :) Maybe tieing in to winner-mode (which I have up anyway...) -bcd
For me this fixes it. Gabor On Tuesday 27 April 2004 21:37, Brian Downing wrote:
This doesn't seem to work quite right for me. Here's how.
1. Start emacs. I have one frame with one window that's *scratch*. 2. M-x slime. (Mine happens to be OpenMCL.) 3. Slime loads. Now I have two windows, *scratch* on top, and *slime-repl[1]* on bottom, selected. 4. I only want the REPL, so I C-x 1, making slime-repl take the whole screen. 5. I type "(symb<TAB>". It completes to "(symbol", and the completions pop up in a window at the bottom of the screen. 6. I want symbol-macrolet, so I type "-m<TAB>". It completes symbol-macrolet. But my window is still split; *scratch* has taken the place of *Completions*. I banished *scratch* above, I don't want to see it again.
I find this more annoying than just having the completions stay up, since at least they have some bearing on my Lisp work.
I think it should restore the window configuration that was there before the completions popped up, unless windows manipulation commands were run in the interim, in which cast the user would be annoyed when whatever he did disappeared.
Unfortunately I have no clue how to do this. :) Maybe tieing in to winner-mode (which I have up anyway...)
-bcd
Brian Downing <bdowning@lavos.net> writes:
I find this more annoying than just having the completions stay up, since at least they have some bearing on my Lisp work.
Should be fixed in CVS.
I think it should restore the window configuration that was there before the completions popped up, unless windows manipulation commands were run in the interim, in which cast the user would be annoyed when whatever he did disappeared.
I agree. It's better to keep the windows alone if we cannot restore the window configuration. Helmut.
participants (5)
-
Brian Downing -
Camille Troillard -
Gabor Melis -
Helmut Eller -
Tiago Maduro-Dias