[Reported to author(s) by email earlier this year]
Emacs `choose-completion' (choosing a completion from the *Completions* buffer) always replaces text upto (point). So the code which figures out an `unambiguous-completion-length' and places the point there in `slime-expand-abbreviations-and-complete' causes problems: the replacement text gets garbled.
(setq slime-complete-symbol-function 'slime-complete-symbol* slime-complete-symbol*-fancy nil pop-up-windows nil pop-up-frames nil)
In the slime-repl buffer at the prompt, put the string "swank::c-s" and type TAB or M-TAB, and choose any item, say swank::compilation-speed. On finding your way back to the repl buffer, you see the garbled text.
For eg; if the string was "(swank::c-s" M-TAB, on finding your way back to the repl buffer, you'll see: "swank::compilation-speed-s" and no paren.
This has been around for ever. I believe the following Changelog entries apply.
| 2004-02-29 Helmut Eller e9626484@stud3.tuwien.ac.at | 2003-11-03 Helmut Eller e9626484@stud3.tuwien.ac.at
The fix that gets rid of the bogus `unambiguous-completion-length' is appended.
Index: slime.el =================================================================== RCS file: /project/slime/cvsroot/slime/slime.el,v retrieving revision 1.698 diff -u -r1.698 slime.el --- slime.el 7 Dec 2006 11:08:57 -0000 1.698 +++ slime.el 10 Dec 2006 13:00:21 -0000 @@ -6096,15 +6097,10 @@ (set-window-start window (point-min) nil) (let ((other-window-scroll-buffer (window-buffer window))) - (scroll-other-window))))) - (let ((unambiguous-completion-length - (loop for c in completion-set - minimizing (or (mismatch completed-prefix c) - (length completed-prefix))))) - (goto-char (+ beg unambiguous-completion-length)) - (slime-display-completion-list completion-set - completed-prefix) - (slime-complete-delay-restoration)))))))) + (scroll-other-window))))) ; madhu + (slime-display-completion-list completion-set + completed-prefix) + (slime-complete-delay-restoration)))))))
(defun slime-complete-symbol*-fancy-bit () "Do fancy tricks after completing a symbol.
* Madhu [2006-12-10 14:09+0100] writes:
[Reported to author(s) by email earlier this year]
Who are the authors?
The fix that gets rid of the bogus `unambiguous-completion-length' is appended.
I don't use this myself, but I committed your patch anyway.
Helmut.
On Thu, 14 Dec 2006 22:05:02 +0100, Helmut Eller heller@common-lisp.net wrote:
The fix that gets rid of the bogus `unambiguous-completion-length' is appended.
I don't use this myself, but I committed your patch anyway.
I just updated and I have to say I very much prefer the previous version (and I never had problems with it).
Would someone object to, cough, making this configurable? I might volunteer to do that.
Cheers, Edi.
* Edi Weitz [2006-12-15 13:11+0100] writes:
I just updated and I have to say I very much prefer the previous version (and I never had problems with it).
Would someone object to, cough, making this configurable?
But it is already configurable. You can rebind the key, set the slime-complete-symbol-function variable, and there is even a slime-complete-symbol*-fancy variable.
I think it would be better to just revert the patch.
Helmut.
On Fri, 15 Dec 2006 16:54:47 +0100, Helmut Eller heller@common-lisp.net wrote:
But it is already configurable. You can rebind the key, set the slime-complete-symbol-function variable, and there is even a slime-complete-symbol*-fancy variable.
Yes, but none of these really copes with the "bogus `unambiguous-completion-length'" problem Madhu had.
I think it would be better to just revert the patch.
Fine with me.
* Edi Weitz ubqm5s6jt.fsf@agharta.de : | On Thu, 14 Dec 2006 22:05:02 +0100, Helmut Eller wrote: |>> The fix that gets rid of the bogus `unambiguous-completion-length' |>> is appended. |> |> I don't use this myself, but I committed your patch anyway. | | I just updated and I have to say I very much prefer the previous | version (and I never had problems with it).
Can you please test the following scenario with your origial setup, and let me know if you get a different result?
From m3fybn7v8c.fsf@robolove.meer.net
(setq slime-complete-symbol-function 'slime-complete-symbol* slime-complete-symbol*-fancy nil pop-up-windows nil pop-up-frames nil)
In the slime-repl buffer at the prompt, put the string "swank::c-s" and type TAB or M-TAB, and choose any item, say swank::compilation-speed. On finding your way back to the repl buffer, you see the garbled text.
For eg; if the string was "(swank::c-s" M-TAB,
(or Esc Tab)
on finding your way back to the repl buffer, you'll see: "swank::compilation-speed-s" and no paren.
Does your input get garbled? (I had convinced myself before posting that fix that the existing code was wrong, and wish to know what I'm missing, Thanks) -- Madhu
On Fri, 15 Dec 2006 23:01:16 +0530, Madhu enometh@meer.net wrote:
Can you please test the following scenario with your origial setup, and let me know if you get a different result?
From m3fybn7v8c.fsf@robolove.meer.net
(setq slime-complete-symbol-function 'slime-complete-symbol* slime-complete-symbol*-fancy nil pop-up-windows nil pop-up-frames nil)
I had tried that yesterday already. It didn't work for me at all - I got "buffer is read-only" error messages.
However, I regularly use slime-complete-symbol* as my completion function (but with other pop-up settings) and my text never got garbled. And I liked the behaviour where point was directly after the shortest unambiguous prefix.
Cheers, Edi.
* Edi Weitz ubqm4292g.fsf@agharta.de : | I had tried that yesterday already. It didn't work for me at all - I | got "buffer is read-only" error messages.
Did you choose a completion (from several alternatives) from the *Completions* buffer, by <Enter> or clicking on it?
I believe The "buffer is read only" error messages also expose the bug, and occurs because slime-repl-face has text properties read-only, while the code accesses parts of the input it shouldnt. This probably masks the bug being addressed. Again, I had convinced myself before posting that fix that the existing code was wrong, and still wish to know what I'm missing
| However, I regularly use slime-complete-symbol* as my completion | function (but with other pop-up settings) and my text never got | garbled. And I liked the behaviour where point was directly after the | shortest unambiguous prefix.
Perhaps you could tell me what settings you use? I almost always use slime inside an emacs running under terminal, with only one frame, but tried other settings too, and the text invariably got garbled.
As for reverting the change, I dont mind as I have been fixing this locally for years. The fact is I found slime-completion* unusable without fixing it, which is why I was surprised no one had complained before. -- Regards Madhu
On Sat, 16 Dec 2006 06:57:05 +0530, Madhu enometh@meer.net wrote:
Did you choose a completion (from several alternatives) from the *Completions* buffer, by <Enter> or clicking on it?
Yes.
I believe The "buffer is read only" error messages also expose the bug, and occurs because slime-repl-face has text properties read-only, while the code accesses parts of the input it shouldnt. This probably masks the bug being addressed. Again, I had convinced myself before posting that fix that the existing code was wrong, and still wish to know what I'm missing
No idea, but as I said I never had problems with the existing code and I always use slime-complete-symbol*. I'm also using the same algorithm in LW-ADD-ONS.
Perhaps you could tell me what settings you use?
These should be the relevant ones:
(slime-setup)
(setq slime-complete-symbol*-fancy t slime-multiprocessing t slime-repl-enable-presentations nil slime-conservative-indentation nil slime-complete-symbol-function 'slime-complete-symbol* common-lisp-hyperspec-root "file:///C:/Program%20Files/LispWorks/lib/4-4-0-0/manual/online/web/CLHS/" common-lisp-hyperspec-symbol-table "C:/Progra~1/LispWo~1/lib/4-4-0-0/manual/online/web/CLHS/Data/Map_Sym.txt" hyperspec-mop-page "file:///c:/home/lisp/doc/mop/dictionary.html")
(add-hook 'lisp-mode-hook (lambda () (set (make-local-variable 'adaptive-fill-mode) nil) (slime-mode t)))
I almost always use slime inside an emacs running under terminal,
I rarely do that. But when I did, I didn't have problems.
with only one frame, but tried other settings too, and the text invariably got garbled.
Not for me.
As for reverting the change, I dont mind
OK.
as I have been fixing this locally for years. The fact is I found slime-completion* unusable without fixing it, which is why I was surprised no one had complained before.
Seems you're using some setting that's different.
Cheers, Edi.
Did you choose a completion (from several alternatives) from the *Completions* buffer, by <Enter> or clicking on it?
Yes.
OK. As I mentioned in my original post, Emacs [GNU emacs] `choose-completion' (choosing a completion from the Completions buffer) always replaces text upto (point). The code unambiguous-completion-length moves the point to a different location, and can move it to a lower position. If the point is moved to a lower location, the text SHOULD get garbled.
So if the choose-completion function is invoked, and succeeds, it will fail garble text as per the specification of emacs completion functions. If the text properties are set to disable modification, then choose-completion will fail. Eitherway the behaviour is incorrect. (This is all to the best of my knowledge/ Emacs 21, 22/ and CMUCL if that matters)
I'm still surprised that it (the posted test case) works for you. -- Best Regards Madhu
-
Edi Weitz -
enometh＠meer.net -
Helmut Eller -
Madhu