From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] `completing-read` - allow history=t, sorting improvements Date: Mon, 19 Apr 2021 21:55:17 -0400 Message-ID: References: <66a96995-10ec-f466-530c-87d173cdfaba@mendler.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31523"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Daniel Mendler Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Apr 20 03:56:38 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lYfd0-000882-6w for ged-emacs-devel@m.gmane-mx.org; Tue, 20 Apr 2021 03:56:38 +0200 Original-Received: from localhost ([::1]:53982 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lYfcz-00037M-A3 for ged-emacs-devel@m.gmane-mx.org; Mon, 19 Apr 2021 21:56:37 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37570) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lYfbp-0002ay-4i for emacs-devel@gnu.org; Mon, 19 Apr 2021 21:55:25 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:22680) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lYfbl-00004y-Ao for emacs-devel@gnu.org; Mon, 19 Apr 2021 21:55:24 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id CF59744199B; Mon, 19 Apr 2021 21:55:19 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 6348A44196C; Mon, 19 Apr 2021 21:55:18 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1618883718; bh=+tds9/ozDgvb6/CUxucKJpG1lsJSZvhouBdAeRV5fWc=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=DaI28NlZC4k4F4a6ZZrPnT2LG8ceHmdV4HchzFNeXb7IDyNpzJmX9AReL88PpAlM3 tmXLtJoOTb0qWBw0nBp5M3Vr8HYiEH9Cbeked+QCG+EzlYR6rvpi9T2rq4/89G6wIY TAIDgpxLOcoqtzuX6Fc7RvsqeK4TEAJXFTeX3iCZO6EOJgZerCBvy7OClhl2ezIwGS gXqrFL6B+UTRPRVg59WjByleb8aQgckoSh8g15k+8sCLHy+67JDI3HiWRCObzBLlRr jwwW6a87FrROAZKcSS6OJ1ogCoiNr/giqx/tMyMqGXda+Zag2G2IOW9zE88VLJbFlb HsVG0uaW6xS1A== Original-Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 2E93C1201BE; Mon, 19 Apr 2021 21:55:18 -0400 (EDT) In-Reply-To: <66a96995-10ec-f466-530c-87d173cdfaba@mendler.net> (Daniel Mendler's message of "Tue, 20 Apr 2021 01:47:34 +0200") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:268199 Archived-At: >> I hope that using (cdr last) will make it unnecessary to use such a hack. >> If not, then please try and use the `category` from `md` rather than >> `minibuffer-completing-file-name` which I consider as obsolete (tho it's >> not marked as such yet). > I will check. I still believe a tiny hack is needed because of the final > slash. I suggest you explain why with a concise example in a comment. As I said, I strive to eliminate such backend-specific hacks, and while I haven't managed to eliminate them all, I find it's important to document them well. > And the advantage of dropping everything behind the slash is that > accesses to files influence the position of their parent directory (if one > considers that an advantage). I don't really understand what you're describing, but it reminds me of something else: for entries which aren't found in the history, we could look for "similar" entries. So, e.g. if you recently used many `gnus-*` commands recently, the other `gnus-*` commands would also be bumped up in the list. But this probably requires much more sophisticated code than what we have currently (e.g. computing some kind of "distance" between strings and weighing the value of a candidate based on its distance to the various history entries). We could start with a distance based on the "length of common prefix", (length (try-completion "" (list candidate (nth i history)))) which would need to be combined with `i` somehow. And if we want to avoid the N=B2 behavior, we'll need to use something like `radix-tree`. > Thanks for letting me know about the `minibuffer-completing-file-name` > variable. There is also `minibuffer-completing-symbol`. Shall we mark th= em > as obsolete? We should, but first we need to correct the places where we still use them. > I wondered why they exist but I took them thankfully as an easy > way to access the category. They predate the `completion-metadata`. Stefan