"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