Hi,
I'm wondering how others use slime-fuzzy-complete-symbol? Do you use it at all? Do you use it with the default user interface or do you have customized it?
I think it's great but the user interface could be tuned a little bit. (at least to my taste)
Here is my idea (which I might eventually implement): - in the source window use <TAB> key to show the fuzzy completion list - simultanously in the match window display the possible matches and highlight the first one as being the current fuzzy completion - do not change anything in the source window and let the focus stay there (this is different from the one currently implemented) - use the subsequent <TAB> keypresses to iterate through the possible matches and use S-<TAB> to go backwards. one can always switch to the completion list window and navigate back and forth with the usual keystrokes if one wants to - otherwise the focus stays in the source window and no changes there - if you hit any key that clearly stops editing the current symbol in the source window, then the incomplete symbol will be replaced by the current fuzzy match and the key will be evaluated afterwards (implicit completion). such keys are space, enter, (), arrow keys leaving the symbol, etc... of course, hide completion window - if you did not find a match or there are too many matches, you can continue editing by navigating back, deleting back, etc. - the completion window remains there and continuously updates making the first match as the current completion, so that you can hit space, enter, () to commit
to type in slot-value-using-class one would type:
( svuc TAB SPACE object SPACE slot )
levy -- There's no perfectoin
Hi,
"Levente Mészáros" levente.meszaros@gmail.com writes:
Hi,
I'm wondering how others use slime-fuzzy-complete-symbol? Do you use it at all? Do you use it with the default user interface or do you have customized it?
I added the following function (just a minor change on slime-fuzzy-select):
(defun slime-fuzzy-select-and-space () "Selects the current completion, making sure that it is inserted into the target buffer with an extra space. This tells the connected Lisp what completion was selected." (interactive) (when slime-fuzzy-target-buffer (let ((buff slime-fuzzy-target-buffer)) (slime-fuzzy-select) (with-current-buffer buff (insert-and-inherit " ")))))
and changed the completion map:
(defvar slime-fuzzy-completions-map (let* ((map (make-sparse-keymap)))
... (define-key map " " 'slime-fuzzy-select-and-space) ...) "Keymap for slime-fuzzy-completions-mode.")
This takes advantage of the fact that, in most cases, fuzzy completion places the cursor on the correct completion so I don't really look at the completions window because the correct completion was also placed on my buffer. Then, I press a space and (because the focus was on the completion window, the command confirms the choice, and I keep writing.
This small change is, IMHO, a good improvement for fuzzy completion usability.
Best regards,
António Leitão.
On Mon, May 08, 2006 at 04:08:12PM +0100, Antonio Menezes Leitao wrote:
(defvar slime-fuzzy-completions-map (let* ((map (make-sparse-keymap)))
... (define-key map " " 'slime-fuzzy-select-and-space) ...)"Keymap for slime-fuzzy-completions-mode.")
This takes advantage of the fact that, in most cases, fuzzy completion places the cursor on the correct completion so I don't really look at the completions window because the correct completion was also placed on my buffer. Then, I press a space and (because the focus was on the completion window, the command confirms the choice, and I keep writing.
This small change is, IMHO, a good improvement for fuzzy completion usability.
I had made space be "next page" to comply with the seemingly standard emacs read-only buffer metaphor of space being page down, backspace being page up, and q being quit. But I agree for using the fuzzy completor for normal everyday completion this could be a really useful feature.
While we're talking about this, would it be helpful for it to try and "learn" your prefered completions? i.e. if one completes "mvl" and picks "multiple-values-limit", that would get a higher score next time. While this would promote trying to have the right completion at the top, it would also mean the list is always shuffling around a bit, which could be distracting. (I put a fuzzy-completion-selected hook in Swank with the expectation of doing something like this, but never used it.)
-bcd
bdowning@lavos.net (Brian Downing) writes:
While we're talking about this, would it be helpful for it to try and "learn" your prefered completions? i.e. if one completes "mvl" and picks "multiple-values-limit", that would get a higher score next time.
That seems like a good idea.
While this would promote trying to have the right completion at the top, it would also mean the list is always shuffling around a bit, which could be distracting.
Humm, I don't really remember what was on the completion window last time I saw it, so I would say that's not a problem.
Another very good improvement would be anything that speeds up the computation of the completions. It is taking too long for normal interactive use, at least in my centrino laptop.
Best regards,
António Leitão.
On Mon, May 08, 2006 at 06:49:33PM +0100, Antonio Menezes Leitao wrote:
Another very good improvement would be anything that speeds up the computation of the completions. It is taking too long for normal interactive use, at least in my centrino laptop.
Okay, there has been no though paid to optimization of the completion core, so speedups shouldn't be hard. I've never had a problem with it though.
-bcd
On Mon, May 08, 2006 at 01:03:08PM -0500, Brian Downing wrote:
On Mon, May 08, 2006 at 06:49:33PM +0100, Antonio Menezes Leitao wrote:
Another very good improvement would be anything that speeds up the computation of the completions. It is taking too long for normal interactive use, at least in my centrino laptop.
Okay, there has been no though paid to optimization of the completion core, so speedups shouldn't be hard. I've never had a problem with it though.
I've committed some micro-optimizations and un-generalizations (i.e. it only works on simple-strings now), which have resulted in a speed increase of about 4-5x for the core algorithm on SBCL. At this point most of the time is spent on the emacs side rendering the buffer for long result lists, which I don't know how to optimize. There's a currently unused LIMIT argument to the FUZZY-COMPLETIONS slimefun. This will only send a certain number of results back to emacs, which may help with rendering speed at the cost of missing low-scoring results.
I've only got SBCL and Lispworks to test with here, so please let me know if I've broken things for your favorite Lisp.
2006-05-24 Brian Downing bdowning@lavos.net
* swank.lisp (recursively-compute-most-completions & friends): Micro-optimize the fuzzy completion engine, improving performace by a factor of about 4 on SBCL. However, it will only work on simple-strings now, and CHAR= is burned in instead of being an option. I don't think this is too much of a limitation. At this point rendering the results on the emacs side takes much longer than finding them for long result lists.
Hope this helps, -bcd
On Mon, May 08, 2006 at 03:43:50PM +0200, Levente M?sz?ros wrote:
I think it's great but the user interface could be tuned a little bit. (at least to my taste)
Here is my idea (which I might eventually implement):
- in the source window use <TAB> key to show the fuzzy completion list
- simultanously in the match window display the possible matches and
highlight the first one as being the current fuzzy completion
- do not change anything in the source window and let the focus stay
there (this is different from the one currently implemented)
- use the subsequent <TAB> keypresses to iterate through the possible
matches and use S-<TAB> to go backwards. one can always switch to the completion list window and navigate back and forth with the usual keystrokes if one wants to
- otherwise the focus stays in the source window and no changes there
- if you hit any key that clearly stops editing the current symbol in
the source window, then the incomplete symbol will be replaced by the current fuzzy match and the key will be evaluated afterwards (implicit completion). such keys are space, enter, (), arrow keys leaving the symbol, etc... of course, hide completion window
- if you did not find a match or there are too many matches, you can
continue editing by navigating back, deleting back, etc.
- the completion window remains there and continuously updates making
the first match as the current completion, so that you can hit space, enter, () to commit
to type in slot-value-using-class one would type:
( svuc TAB SPACE object SPACE slot )
I think that exact interface would probably drive me nuts, but then again since I wrote the existing one it's pretty optimized for how I like it. :)
All of the swank calls for fuzzy-completion are pretty general - it should be relatively easy to wrap a completely new emacs-side interface around it, which sounds like what you're talking about above. Digging a little deeper, you have:
(defun compute-highest-scoring-completion (short full test) "Finds the highest scoring way to complete the abbreviation SHORT onto the string FULL, using TEST as a equality function for letters. Returns two values: The first being the completion chunks of the high scorer, and the second being the score." ...)
CL-USER> (swank::compute-highest-scoring-completion "mulvb" "multiple-value-bind" #'char=) ((0 "mul") (9 "v") (15 "b")) 42.391666666666666
...so you can use the core algorithm to complete whatever strings want, not just symbols.
-bcd
-
Antonio Menezes Leitao -
bdowning＠lavos.net -
Levente Mészáros