Re: completion discrepancy between default completion and helm/ivy completions

[Stefan Monnier]

> (when (and org-contacts-enable-completion
>          (boundp 'completion-at-point-functions))
>   (add-hook 'message-mode-hook 'org-contacts-setup-completion-at-point))

> which does

> (defun org-contacts-setup-completion-at-point ()
>   "Add `org-contacts-message-complete-function' as a new function
> to complete the thing at point."
>   (add-to-list 'completion-at-point-functions
>              'org-contacts-message-complete-function))

[ Side point: `add-to-list` is wrong, it should be `add-hook` (tho with
  additional "nil 'local" arguments, to only add to the buffer-local
  part of the hook).  ]

> That function basically checks if this is a place where completion
> should happen (To field, for instance), then calls all the
> org-contacts-complete-functions until one succeeds. One such function is
> org-contacts-complete-group that, in some case, returns a function
> taking unused arguments and returning the completion as a string. To
> summarize, is it okay for a function in completion-at-point-functions to
> return such a function?

The docstring of `completion-at-point-functions` says:

    Each function on this hook is called in turn without any argument and
    should return either nil, meaning it is not applicable at point,
    or a function of no arguments to perform completion (discouraged),
    or a list of the form (START END COLLECTION . PROPS), where:
    [...]

So, yes, it's acceptable (tho discouraged) to return a function, but this
function should then *perform the completion* (rather than just return
a string).

> I guess I should try to return something of the form (start end
> collection . props) instead, with collection being a singleton…

Why a singleton?  The driving design should be: return a `collection`
which is valid for any text between `start` and `end`.

Because `collection` will be matched against the text between `start`
and `end` anyway (and the UI may decide to match it against other text
as well, e.g. to provide other completion styles than just prefix
completion).


        Stefan