Stephen Leake <stephen_leake@stephe-leake.org> writes:

> Dmitry Gutov <dgutov@yandex.ru> writes:
>
>> 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:

"default"; substring style on absolute file names

uniquified-file: complete on basename, then on appended uniquifying
directories.

(Juri Linkov mentioned a style like this in
https://lists.gnu.org/archive/html/emacs-devel/2019-01/msg00081.html)

file-root-rel: complete on filenames relative to the project root
(assumes a single root).

Also attached are emacs-project.el, uniquify-test-project.el, providing
example projects used in the demo.

A few points:

The file names may want to change; file-root-rel reuses some of
uniquify-file, and 'uniquify-file' might be better named
'file-basename'.

project-file-completion-table can return a list of files, so a 
backend can use 'git ls' or 'find' to implement it. That is no harder to
implement than 'project-files'.

The uniquify-file completion style works on a list of files; see the
demo case with
(uniquify-test-project-completion-style 'default)
(project-file-completion-styles '(uniquify-file))

However, file-root-rel does not, because the root directory must be
stored somewhere that is accessible from the completion code.
project--completing-read-strict handles this by wrapping a list in a
completion table function. We could use a global variable to store the
root instead, but that's not much better.

If there are other completion styles that have global data stored
somewhere, perhaps it would make sense to introduce a root defstruct for
completion styles, store the completion table and data in that object,
and pass that to completion functions instead of the completion table.
That could be backward compatible; completion functions would check for
the defstruct as well as for a function or a list.

Note that project--completing-read-strict let-binds both
completion-category-overrides and completion-styles, in order to handle
all the possible choices.

Some completion table functions require a particular style, mostly for
optimization reasons, but also for the global data issue; that is
indicated by returning a "style" metadata.

Some backends will want to specify the style; Ada works well with
uniquify-file, since the file basenames are required to be unique. Java
works well with file-root-rel, since the directory part of the basename
is significant.

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. It also adds a "style" metadata to the completion table function
API. Together with the advice on completing-read-default and
test-completion, this could be moved to minibuffer.el.

-- 
-- Stephe