From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: A dynamic pattern-matching Date: Tue, 03 Mar 2009 20:11:54 -0500 Message-ID: References: <18860.59659.494547.384677@moose.fleuret.org> <18861.41519.484433.255547@moose.fleuret.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1236129130 26400 80.91.229.12 (4 Mar 2009 01:12:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 4 Mar 2009 01:12:10 +0000 (UTC) Cc: emacs-devel@gnu.org To: Francois Fleuret Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 04 02:13:26 2009 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.50) id 1Leffo-00034S-UZ for ged-emacs-devel@m.gmane.org; Wed, 04 Mar 2009 02:13:25 +0100 Original-Received: from localhost ([127.0.0.1]:33528 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LefeT-0007Nf-Hw for ged-emacs-devel@m.gmane.org; Tue, 03 Mar 2009 20:12:01 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LefeP-0007Na-Jc for emacs-devel@gnu.org; Tue, 03 Mar 2009 20:11:57 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LefeP-0007NO-0G for emacs-devel@gnu.org; Tue, 03 Mar 2009 20:11:57 -0500 Original-Received: from [199.232.76.173] (port=55457 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LefeO-0007NL-PL for emacs-devel@gnu.org; Tue, 03 Mar 2009 20:11:56 -0500 Original-Received: from ironport2-out.pppoe.ca ([206.248.154.182]:2509 helo=ironport2-out.teksavvy.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LefeO-0002YT-Ih for emacs-devel@gnu.org; Tue, 03 Mar 2009 20:11:56 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApAFAC5krUnO+KX2/2dsb2JhbACBTtU+hAgGhAE X-IronPort-AV: E=Sophos;i="4.38,297,1233550800"; d="scan'208";a="34663062" Original-Received: from 206-248-165-246.dsl.teksavvy.com (HELO pastel.home) ([206.248.165.246]) by ironport2-out.teksavvy.com with ESMTP; 03 Mar 2009 20:11:55 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 051324B454; Tue, 3 Mar 2009 20:11:55 -0500 (EST) In-Reply-To: <18861.41519.484433.255547@moose.fleuret.org> (Francois Fleuret's message of "Tue, 3 Mar 2009 22:33:35 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.91 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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:109428 Archived-At: >> - it'd be easy to write a variant of icomplete-mode that addresses >> point 1 by using a separate buffer (which we'd call >> "*Completions*"). > Well, that's not clear to me. IIUC completing-read and other functions > of that kind blocks the calling program until the user makes up his > mind, while my selector/select uses a callback. > In fact, is it really desirable to use that selector in place of the > standard completion functions ? My idea was more to provide an > alternative to recentf-open-files and switch-buffer. Yes, both issues relate to "point 6", i.e. the API. Yours is non-modal (well, the minibuffer is not 100% modal, since you can do something else while a minibuffer is open, especially if you set enable-recursive-minibuffers, but it imposes a strict nesting). The idea of integrating the two, is that users can then use yours without changing the corresponding code to use your API. Users could choose which interaction mode to use for which commands. Or even provide a command to dynamically switch interaction mode directly from the minibuffer. >> - point 4 can be simulated by adding a "*" at the beginning of >> the pattern. Or we could add a `substring' completion-style. > Yes. But I would vote for having a variable that specifies how the > typed pattern has to be interpreted { substrings, regexp, > leadingstring } or something. >> - point 5 hopefully can be implemented as a completion-style. > Not sure to understand what you do mean here. To get a vague idea of what I'm talking about check `completion-styles' as well as `completion-styles-alist'. Stefan