duplication + company-kind combinator

[jdtsmith]

Just noticed two issues when super-capf'ing dabbrev + elisp backend, ala:

    (setq-local completion-at-point-functions
        `(,(cape-super-capf
            #'cape-dabbrev
            (cape-capf-with-predicate
             #'elisp-completion-at-point
             #'my/ignore-elisp-keywords))
          cape-file)

1. Results from a single CAPF are doubling-up. I don't know if this is specific to the dabbrev pairing, but it does not appear to be dabbrev and normal CAPF each having the same candidate (though it could be).
2. If one capf supports company-kind, and the other doesn't, kind-icon cannot tell the difference between "I don't do kind" and "I do kind, but not for this candidate". Right now it's putting up an ugly "unknown" icon, but even if I correct that to make it a "blank" icon, now I get blanks for everything, even if an entire candidate list has no kind. I'm not sure of a good solution other than "don't combine CAPFs with disparate kind availability". I know this one is solved in Emacs 28 for example.

Screen shot:

[minad]

Results from a single CAPF are doubling-up. I don't know if this is specific to the dabbrev pairing, but it does not appear to be dabbrev and normal CAPF each having the same candidate (though it could be).

Oh, right. This can happen. I will fix this and drop duplicates, preferring the candidate from the first capf. (EDIT: Fixed in https://github.com/minad/cape/commit/4b424150ef1d9d179339864d097caf0621a83f3a).

If one capf supports company-kind, and the other doesn't, kind-icon cannot tell the difference between "I don't do kind" and "I do kind, but not for this candidate". Right now it's putting up an ugly "unknown" icon, but even if I correct that to make it a "blank" icon, now I get blanks for everything, even if an entire candidate list has no kind.

You should correct the ugly icon. You won't get blanks for everything, only for the candidates which don't have an associated kind function. cape-super-capf uses the appropriate company-kind function for each candidate.

[jdtsmith]

EDIT: Fixed in 4b42415

Works thanks. I also discovered (I hope) that order is relevant in the super-capf; by placing dabbrev last on the super-list, I get them as backups. Unless this is an accident of HT ordering? If not, worth adding to the docstring.

You should correct the ugly icon. You won't get blanks for everything, only for the candidates which don't have an associated kind function.

I now just show the kind=t unknown-ish icon for the missing ones. So you get no kind icon at all only when there is not a capf. Not ideal, but better than blank/nothing, and will encourage people to ask backends to provide kinds.

[minad]

Works thanks. I also discovered (I hope) that order is relevant in the super-capf; by placing dabbrev last on the super-list, I get them as backups. Unless this is an accident of HT ordering? If not, worth adding to the docstring.

Yes, the candidates are grouped by sub capf.