In BEIRC, one can end up with an enormously long list of candidate possibilities for completing a command, because IRC has so many commands. The possibilities are not ordered at all, so the list is pretty much useless.
The following patch to input-editing would fix this problem by sorting the set of possibilities alphabetically.
I realize that this may not be optimal, because it's a "one size fits all" solution. OTOH, it's clearly better than just getting an arbitrarily permuted list, so I suggest that it be adopted.
I have commit privs, but have mostly used them for documentation and Allegro-specific compatibility fixes, so I'd love some validation (or reasoned rejection) before committing.
Thanks all, R
P.S. It occurs to me that we could avoid pointlessly sorting length 1 lists by dumping the call to sort inside the VALUES call in the ELSE branch of the final if of complete-from-generator-possibilies. But that shouldn't change the question of whether this is a good idea or not...
--- input-editing.lisp 10 Mar 2006 21:58:13 -0000 1.49 +++ input-editing.lisp 7 Apr 2006 19:00:18 -0000 @@ -781,6 +781,9 @@ (defun complete-from-generator-possibili (incf nmatches) (push (cons str obj) possibilities)))) (funcall generator initial-string #'suggester) + ;; attempting to get the list of candidates sorted [2006/04/07:rpg] + (setf possibilities + (sort possibilities #'string-lessp :key #'car)) (if (and (eql nmatches 1) (string-equal initial-string (caar possibilities))) (values (caar possibilities)
rpgoldman@real-time.com writes:
In BEIRC, one can end up with an enormously long list of candidate possibilities for completing a command, because IRC has so many commands. The possibilities are not ordered at all, so the list is pretty much useless.
The following patch to input-editing would fix this problem by sorting the set of possibilities alphabetically.
I deal with this by providing functions such as COMPLETE-FROM-POSSIBILITIES with presorted lists of possibilities.
Paolo
"PA" == Paolo Amoroso amoroso@mclink.it writes:
PA> rpgoldman@real-time.com writes: >> In BEIRC, one can end up with an enormously long list of >> candidate possibilities for completing a command, because IRC >> has so many commands. The possibilities are not ordered at >> all, so the list is pretty much useless. >> >> The following patch to input-editing would fix this problem by >> sorting the set of possibilities alphabetically.
PA> I deal with this by providing functions such as PA> COMPLETE-FROM-POSSIBILITIES with presorted lists of PA> possibilities.
OK. The alternative solution would involve modifying the ACCEPT presentation method for COMMAND-NAME in commands.lisp. The problem is that this would now involve a bunch of consing, because I'd have to enumerate all the commands, sort them, and then call the suggester on them. But perhaps that's a better choice.
Follow-up question: This is being done by complete-from-generator, rather than complete-from-possibilities. So I don't explicitly create the list of possibilities; instead I have a loop that does a bunch of calls to SUGGEST.
A skim of the spec doesn't seem to show any guarantee that the possibilities you get will appear in the same order they were added by suggest. So does your solution work in this location?
Note that this patch (I believe) only applies to complete-from-generator, which doesn't have an obvoiusly good alternative (unless we have the suggest guarantee I refer to above).
Any suggestions?
thanks, r
"PA" == rpgoldman rpgoldman@real-time.com writes:
"PA" == Paolo Amoroso amoroso@mclink.it writes:
PA> rpgoldman@real-time.com writes: >>> In BEIRC, one can end up with an enormously long list of >>> candidate possibilities for completing a command, because IRC >>> has so many commands. The possibilities are not ordered at >>> all, so the list is pretty much useless. >>> >>> The following patch to input-editing would fix this problem by >>> sorting the set of possibilities alphabetically.
PA> I deal with this by providing functions such as PA> COMPLETE-FROM-POSSIBILITIES with presorted lists of PA> possibilities.
PA> OK. The alternative solution would involve modifying the PA> ACCEPT presentation method for COMMAND-NAME in commands.lisp. PA> The problem is that this would now involve a bunch of consing, PA> because I'd have to enumerate all the commands, sort them, and PA> then call the suggester on them. But perhaps that's a better PA> choice.
PA> Follow-up question: This is being done by PA> complete-from-generator, rather than PA> complete-from-possibilities. So I don't explicitly create the PA> list of possibilities; instead I have a loop that does a bunch PA> of calls to SUGGEST.
PA> A skim of the spec doesn't seem to show any guarantee that the PA> possibilities you get will appear in the same order they were PA> added by suggest. So does your solution work in this PA> location?
PA> Note that this patch (I believe) only applies to PA> complete-from-generator, which doesn't have an obvoiusly good PA> alternative (unless we have the suggest guarantee I refer to PA> above).
To be more clear, I believe that the above entails "this patch would not goof up your ability to send complete-from-possibilities a list sorted however you like it."
Indeed, my solution is almost an instance of yours.
R
-
Paolo Amoroso -
rpgoldman＠real-time.com