From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Completion Date: Sat, 01 Sep 2018 11:14:59 -0400 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1535815267 11286 195.159.176.226 (1 Sep 2018 15:21:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 1 Sep 2018 15:21:07 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 01 17:21:03 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fw7hu-0002ps-Fm for ged-emacs-devel@m.gmane.org; Sat, 01 Sep 2018 17:21:02 +0200 Original-Received: from localhost ([::1]:37564 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fw7k0-000852-Q0 for ged-emacs-devel@m.gmane.org; Sat, 01 Sep 2018 11:23:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44192) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fw7jk-0007gH-2A for emacs-devel@gnu.org; Sat, 01 Sep 2018 11:23:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fw7cC-0001vQ-HS for emacs-devel@gnu.org; Sat, 01 Sep 2018 11:15:11 -0400 Original-Received: from [195.159.176.226] (port=56991 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fw7cC-0001vH-9w for emacs-devel@gnu.org; Sat, 01 Sep 2018 11:15:08 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1fw7a3-0002BI-Tc for emacs-devel@gnu.org; Sat, 01 Sep 2018 17:12:55 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 49 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:HFqqpLeUC9dQeUe7ONCgpAhLgow= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:229163 Archived-At: > Let's say the set is '("foo" "zot") and the string is "fo". Then > there's one match, and it's unique, of course. But it's not exact? So > should it return nil, then? It should return "foo". > 2) The entire `completing-read' machinery is based on prefix, matches > and nothing else; is that right? No. The *completion tables* (i.e. the "objects" that define what completions are available) only offer methods that work for prefixes. But `completing-read` uses completion commands which do a lot more than just let the completion tables do the completion for them. > That is, if you want to do completion on words inside strings (for > instance, if you want "foo" to have a match in a collection string > like "zot foo bar", then there is no built-in machinery in Emacs > for this? There's completion-try-completion and completion-all-completions, both of which offer completions according to completion-styles. > 3) The completion selection machinery in simple.el is nice, but it would > be nice to be able to pass more information about the strings into it > and get it all back after the user has chosen something. The obvious > thing is to put a text property on the strings, and that almost, almost > works, except for this: > > (defun choose-completion (&optional event) > "Choose the completion at point. > If EVENT, use EVENT's position to determine the starting position." > > [...] > > (setq end (or (next-single-property-change end 'mouse-face) > (point-max))) > (buffer-substring-no-properties beg end))))) > > If that had been just `buffer-substring', then the information would > survive back to the caller. > > `minibuffer-allow-text-properties' exists. Would it make sense to add a > new variable, like `completion-allow-text-properties', to handle this > case as well? We could, I guess. What's your use case? Stefan