[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