Add completion-at-point

[emacs-citar]

Add completion-at-point

[minad]

I believe Corfu works reasonably well with long candidates. But in case you want to use shorter candidates there is no other way than writing a separate candidate formatter.

[minad]

I guess many people would like such a functionality. If you have Corfu installed it is pretty simple to get something running with a single completion command. However this won't work with Company. As far as I know, Company does not provide a completion in region function; it only supports completion at point functions.

Probably such completions in region are useful in many contexts. But it seems that completion-in-region is not widely used due to the lack of a user friendly completion UI. Now we have at least Corfu :) The whole Emacs code base has only 14 matches, when grepping for (completion-in-region , in contrast to over 300 matches for completing-read and over 100 matches for completion-at-point-function.

It could be that the use of completion-in-region is generally discouraged and everyone should use completion-at-point instead. With completion-at-point there is the problem that you cannot have multiple completion backends active at the same time.

After grepping the Emacs ChangeLogs, it seems that using completion-in-region is discouraged. Many completion-in-region calls have been converted to capfs. But I think capf and completion-in-region are not mutually exclusive. If you want to use TAB completion, capf is the way to go and if you want to provide separate commands completion-in-region is more appropriate. Both approaches can share the completion table and the candidate generation code.

(defun bibtex-complete ()
  (interactive)
  (pcase (preceding-char)
    (?@ (completion-in-region (- (point) 1) (point) '("@key1" "@key2" "@key3" "@key4")))
    (?[ (completion-in-region (- (point) 1) (point) '("[ref1:" "[ref2:" "[ref3:" "[ref4:")))
    (_ (user-error "No bibtex completion")))))

(global-set-key "\C-q" #'bibtex-complete)

[bdarcus]

Thanks @minad!

You can probably tell I'm not clear on the distinction between completion-in-region and completion-at point!

I think capf and completion-in-region are not mutually exclusive. If you want to use TAB completion, capf is the way to go and if you want to provide separate commands completion-in-region is more appropriate.

I think for this case, we probably just need this for a single command: to insert a citation key, per the screenshot up top.

So maybe we should then target capf?

Both approaches can share the completion table and the candidate generation code.

... and share with the completing-read function too; right?

As in, we'd want to adapt the table that bibtex-read uses (the candidates come from bibtex-actions--format-candidates) to add a propertized string targeted to this UI?

[minad]

So maybe we should then target capf?

Capfs are functions registered in the list completion-at-point-functions. Each function in this list is tried in order if it provides completion. Many modes already provide such a function and the first one taking control will win. It will probably work well if you use a trigger character like @, such that your capf function takes control only if the character before the point is @.

... and share with the completing-read function too; right?

Yes, the completion table can be reused between capf, completion-in-region and minibuffer-completion/completing-read. This is kind of neat about the completion design.

As in, we'd want to adapt the table that bibtex-read uses (the candidates come from bibtex-actions--format-candidates) to add a propertized string targeted to this UI?

I don't understand what you mean by that.

[bdarcus]

As in, we'd want to adapt the table that bibtex-read uses (the candidates come from bibtex-actions--format-candidates) to add a propertized string targeted to this UI?

I don't understand what you mean by that.

The candidates produced for completing-read are frame-width strings optimized for vertical-completion UIs (selectrum, vertico, etc.).

Let me put this instead in the form of a question: how do I address the fact those strings are too long/not designed for capf UIs?

Does what I said above now make better sense?

[bdarcus]

I believe Corfu works reasonably well with long candidates. But in case you want to use shorter candidates there is no other way than writing a separate candidate formatter.

Now that I look again, the existing strings should probably work fine.

[bdarcus]

Added in #132.