[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: project--completing-read-strict breaks ada-mode project completion t
From: |
Stefan Monnier |
Subject: |
Re: project--completing-read-strict breaks ada-mode project completion table |
Date: |
Mon, 11 Feb 2019 16:50:09 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
>>> 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