From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: project--completing-read-strict breaks ada-mode project completion table Date: Mon, 11 Feb 2019 16:50:09 -0500 Message-ID: References: <20180922154639.23195.66360@vcs0.savannah.gnu.org> <20180922154640.9D58220310@vcs0.savannah.gnu.org> <54108dbc-9d12-06ff-3f1d-151118e9b234@yandex.ru> <4e729d1e-bb31-455f-fd44-e99ae5a6b9fa@yandex.ru> <86zhs5r9lr.fsf_-_@stephe-leake.org> <08de4d90-d678-0524-9356-f9a3515bf0c4@yandex.ru> <86a7k2rabi.fsf@stephe-leake.org> <86sgxso27d.fsf@stephe-leake.org> <69076784-83cb-5cc7-be39-fea990b8535e@yandex.ru> <861s55n6wk.fsf@stephe-leake.org> <86lg2swg14.fsf@stephe-leake.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="182838"; mail-complaints-to="usenet@blaine.gmane.org" 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 Mon Feb 11 22:50:43 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gtJTP-000lTb-F2 for ged-emacs-devel@m.gmane.org; Mon, 11 Feb 2019 22:50:43 +0100 Original-Received: from localhost ([127.0.0.1]:56786 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gtJTO-0005hv-E2 for ged-emacs-devel@m.gmane.org; Mon, 11 Feb 2019 16:50:42 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:41435) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gtJTE-0005hl-9b for emacs-devel@gnu.org; Mon, 11 Feb 2019 16:50:33 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gtJTD-000515-4h for emacs-devel@gnu.org; Mon, 11 Feb 2019 16:50:32 -0500 Original-Received: from [195.159.176.226] (port=53916 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gtJTC-0004uP-OT for emacs-devel@gnu.org; Mon, 11 Feb 2019 16:50:30 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1gtJT2-000l6x-PT for emacs-devel@gnu.org; Mon, 11 Feb 2019 22:50:20 +0100 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:pPhzVxmsf5x0u/jgMMSQjGqO44g= 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:233228 Archived-At: >>> And again, it doesn't have to be a separate command, the behavior >>> could be customizable and dispatched inside the one command's >>> implementation. > I've now implemented this. > Gnu ELPA has updated versions of path-iterator and uniquified-files. > I added a new file completion style; file-root-rel, in > uniquified-files/file-complete-root-relative.el. > > Attached is an elisp file demo-project-file-completion.el, which > rewrites project--completing-read-strict to allow either the user or the > project backend to specify the completion style, and provides examples > of each of three styles: [...] > (table-styles (cdr (assq 'styles (completion-metadata "" collection nil)))) > (completion-category-overrides > (list (list 'project-file (cons 'styles > (or table-styles > project-file-completion-styles))))) > > ;; If the completion table is a list, or a function that does > ;; not return styles metadata, we set completion-styles to > ;; reflect the user choice. > (completion-styles (if table-styles nil project-file-completion-styles)) This gives precedence to the collection's styles with no way for the user to override this choice. This problem is the reason why I designed the current system to go through the indirection of a category, making it possible for the user to override the category's default styles via completion-category-overrides. > The uniquify-file completion style works on a list of files; see the [...] > However, file-root-rel does not, because the root directory must be > stored somewhere that is accessible from the completion code. I don't understand this. Why can't the completion style compute the common-prefix? > uniquify-files.el now adds two functions to completion-styles-alist, for > converting strings from user to table input format, or user to data > format. As I mentioned in another message to Joćo, I think we should move from completion-style-alist to using generic functions that dispatch on the style. Also, I don't quite understand why we need 2: they both seem to implement the same direction of the conversion (i.e. from "user-string" to "data-string"). I see that uniq-file-get-data-string does more (i.e. it tries to find the corresponding match if there's only one) but I don't understand why you need to do that: this seems to do a kind of completion which minibuffer-complete-and-exit should already have done (if `require-match` is set) or which shouldn't be done (if `require-match` is not set). > Together with the advice on completing-read-default and > test-completion, this could be moved to minibuffer.el. As you mention in uniquify-files.el: (defun completion-get-data-string (user-string table pred) [...] ;; FIXME: This is ultimately called from ;; `completion-try-completion' or `completion-all-completions'; ;; there is only one style currently being used. Need to pass that ;; style from there to here. it only makes sense to call the conversion function corresponding to the style that was used to generate that string. [ Also while a specific call to minibuffer-complete (or minibuffer-completion-help, or minibuffer-force-complete, ...) only uses a single style, a given completing-read session can currently use several completion styles. ] So I think we should fix this FIXME before we can move this code to minibuffer.el. Maybe we can save the completion style that returned that string in a text-property, or even directly store the conversion function in there (so we don't need to extend completion-style-alist). Stefan