From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "T.V. Raman" Newsgroups: gmane.emacs.devel Subject: minibuffer-completion-help: make sorting of completions customizable? Date: Tue, 25 Jan 2011 13:47:10 -0800 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: dough.gmane.org 1295992048 7940 80.91.229.12 (25 Jan 2011 21:47:28 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 25 Jan 2011 21:47:28 +0000 (UTC) To: Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 25 22:47:22 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PhqjR-0003hR-CZ for ged-emacs-devel@m.gmane.org; Tue, 25 Jan 2011 22:47:21 +0100 Original-Received: from localhost ([127.0.0.1]:40659 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PhqjP-0007Mr-W4 for ged-emacs-devel@m.gmane.org; Tue, 25 Jan 2011 16:47:20 -0500 Original-Received: from [140.186.70.92] (port=56747 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PhqjK-0007Mi-9h for emacs-devel@gnu.org; Tue, 25 Jan 2011 16:47:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PhqjI-0001XM-W2 for emacs-devel@gnu.org; Tue, 25 Jan 2011 16:47:14 -0500 Original-Received: from mail-ey0-f169.google.com ([209.85.215.169]:63302) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PhqjI-0001Wq-Re for emacs-devel@gnu.org; Tue, 25 Jan 2011 16:47:12 -0500 Original-Received: by eyh6 with SMTP id 6so215571eyh.0 for ; Tue, 25 Jan 2011 13:47:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=4giBchibmOxTBH94hzWifE8x7gAMAMSwd7ekvAGhxrY=; b=Vwlzn6+Aj4bKaFSEnbyCmqGTxRV/nQVPfc/9dvGACfbH+fODPjZqashM8CVviyLEDY POhuhSbo/LLw2sWdsRtWsUTACWNJwkeSJKQzhalaptijs5buYzjTryzjDFGKzbSfVXR0 bmUuK6SSQDIXJSaJq6BAB7exp8ruEP93sZ2bk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=B1HhdAAxxcgsUJZE6dg5SG4lB0ljPZx4bCtLgr7LvJ9nWcdqZQcGS5EkPe8ONJ/VwC 7oh6caholHnh6446msXdHyhh6jwhUk2PcUAnXr9avhmHzlYMN8+kAs15qpA7pSDU7/aZ QUMucefLAwy86nnq6/4byqmVYbW0cJEU3drCQ= Original-Received: by 10.213.15.135 with SMTP id k7mr224048eba.26.1295992030903; Tue, 25 Jan 2011 13:47:10 -0800 (PST) Original-Received: by 10.213.14.20 with HTTP; Tue, 25 Jan 2011 13:47:10 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:134963 Archived-At: Stefane, I hear you. I actually spent some time looking through the completion table code to see where things were getting sorted, and had to resort to debug-on-entry to figure out that the sorting happened in minibuffer-completion-help --- so the design you propose is actually the right one. But this somewhat simplistic change I proposed lets me implement google-suggest much better in package g-client which is part of emacspeak http://emacspeak.googlecode.com/svn/trunk/lisp/g-client/gweb.el Basically, Google Suggest gives me the suggestions sorted by number of hits; getting that list sorted using string-lessp loses basdly. -- On 1/25/11, Stefan Monnier wrote: >> As implemented, minibuffer-completion-help *always* sorts the >> completion list using string-lessp. This works most of the time, >> except when the caller has already >> set up the completions to reflect a desired order. Could the >> implementation be updated to provide a setting that could be let >> bound by the caller? > > I've resisted it, because I think the right way is for the > completion-table itself to provide this function (the difference becomes > significant when completing things that are made of various parts, some > of which may be sorted one way and others some other way), but this is > a much more significant change. > > It basically means extending the `boundaries' method into a generic > `meta-info' method that will include not just boundaries but also > sort-order, type (e.g. it can tell whether you're completing buffers, > files, or something else, which can then be associated to a config > variable to use different completion-styles for different types of > data), (un)quoting rules (needed for reliable completion of file names > in *shell* buffers), a different separator than \n to use in the > *Completions* buffer, ... > > > Stefan >