[mcclim-devel] patch for possbility sorting
rpgoldman at real-time.com
rpgoldman at real-time.com
Fri Apr 7 19:38:32 UTC 2006
>>>>> "PA" == rpgoldman <rpgoldman at real-time.com> writes:
>>>>> "PA" == Paolo Amoroso <amoroso at mclink.it> writes:
PA> rpgoldman at 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
More information about the mcclim-devel
mailing list