attempt to implement as-you-type style for corfu-preview-current

[dwuggh]

Hi, I'm trying to implement corfu-candidate-overlay-like preview styles. Since we already have corfu-preview-current now, I only need to change the text properties(cursor and face) in the overlay. as in #331 , you mention that you didn't manage to achieve acceptable performance. I wonder the status of performance now, I think company-preview-frontend does the pretty same thing, updating the overlay on every keystroke.

In corfu, the preview flickers at first, but it seems to be a redisplay issue instead of performance. the code deletes overlay in pre-command-hook and then force redisplay before the new overlay is computed. Commenting out the following code eliminates the flickering, and I don't feel any lags during these days of usage.

corfu/corfu.el

Line 705 in c302b05

(when interruptible (redisplay))

It is related to #48. Could this be further optimized? maybe by changing the overlay update logic? or add another option here?

[minad]

The problem I had seen was that if an inline overlay is shown after the input, it will have to update immediately on every key press such that the overlay is not shifted and letters which already exist at the beginning of the overlay are overridden. Example: pre|<view> (pre is the input, | the cursor and the preview). Now enter v, the overlay should immediately update to prev<iew>.

Now the problem is that recomputing the candidates to recompute the overlay would be too costly. The candidate recomputation would have to happen in an non-interruptible way. One could however use a heuristic and simply delete the first letter from the overlay if it matches. Corfu right now does not have such a problem, since the popup is shown below and as such it doesn't hurt as much visually if the popup lags behind slightly until the user pauses a little bit. Corfu can compute the candidates and interrupt candidate computation.

The second problem is that Corfu supports more flexible completion styles, not only prefix completion. What should the overlay display then? Example: pvw<preview> where pvw is some input handled according to the flex completion style. Then the whole candidate could be shown: <preview>. The question is how update should be handled then.

It would maybe work if one first computes the full set of candidates and on additional input refine/refilter the sorted set of computed candidates given the new input. This way candidate computation would be fast, but could get incoherent if the full set of candidates are computed. As soon as TAB (or some other key) is pressed to display the full candidate list would be displayed and the top candidate would not match anymore the refined previewed candidate.

One could look at the Emacs 30 completion-preview-mode to see how these problems are handled there. (EDIT: I took a look and there the overlay is updated according to the input as I described in the pre<view> -> prev<iew> example. This works but only with prefix completion, i.e., the basic completion style.)

[dwuggh]

thanks! I'll take a look. My idea is that we can make the overlay over entire <preview> and show a propertized string and set the cursor property, so updating overlays will not move it, instead we update the face properties of the propertized string. Then we do not need to delete the overlay until completion quits. With complex styles, it would be something like pvw(origin text) -> <preview>(overlay), or other styles. I think corfu-preview-current already has this idea, just didn't propertized the content.

[jdtsmith]

corfu-auto=preview

Why can't this function on a timer, pretty much identically to corfu-auto=t, but using a different UI paradigm? Instead of showing all candidates in a child-frame popup, corfu-auto=preview shows only the first, as an overlay, like either:

1. prefix or
2. vsg<velo-seismic-gravity>

There would of course be a time delay (corfu-auto-delay) and it would be interruptible, like normal. Just as in corfu-auto, once there is an active completion table during completion, it can be queried repeatedly, just as corfu currently does. Once there are no more candidates, it quits. You can quit it if it's annoying you with C-g. Etc.

I think it would be exactly as performant as corfu-auto already is. It would not be "bare post-command hook" performant, but I don't think it needs to be (and that puts too much stress on CAPFs anyway).

It could even support M-SPC for orderless terms (because again, it's just corfu-auto with a simpler "skin"). Then, as a nicety, completion-at-point could either insert the candidate (for a single candidate only) or pop up the full child frame (whose candidate list is already fully populated, so no additional work to do). This could even inherit the styling capabilities of e.g. orderless or flex. You could even provide a key binding to cycle between candidates (e.g. [S-up/down]) when active.

The only subtlety as I see it is how to "merge" the 1st candidate with the already typed text at point. I think after each update, you just test if what's typed is a prefix of the first candidate to decide style 1 or 2 above. It can even switch midway through.

[minad]

Yes, sure. We should give that a try.

It could even support M-SPC for orderless terms (because again, it's just corfu-auto with a simpler "skin").

I think it is a little more than a different skin, since it also introduces new key bindings via a corfu-preview-map. There would be multiple modes of operation then.

The only subtlety as I see it is how to "merge" the 1st candidate with the already typed text at point. I think after each update, you just test if what's typed is a prefix of the first candidate to decide style 1 or 2 above. It can even switch midway through.

My concerns are mainly around this subtlety and the performance of updating an overlay directly behind the point. This leads to sluggishness in my experience.

[minad]

@jdtsmith I think it may technically be better to refactor Corfu for this functionality, since the

1. Move corfu-auto* functionality to corfu-auto.el extension. Corfu core only contains popup and manual functionality.
2. Add separate corfu-preview.el extension. TAB simply triggers manual Corfu.

[minad]

@jdtsmith As a first step I have moved out the auto completion code to corfu-auto.el in 037d756. We could consider adding a separate corfu-preview.el, or just use completion-preview-mode. I worry a bit that completion-preview-mode deviates from Corfu sorting, and we could probably get overall better behavior with an extra corfu-preview. Not to forget, there is also https://code.bsdgeek.org/adam/corfu-candidate-overlay.

[jdtsmith]

Sounds good. Maybe for a future corfu-preview, two settings for corfu-auto are desirable: preview and preview-single. The latter would function a bit like company: if there is only one candidate at the time corfu-auto runs, use the overlay UI, otherwise, for more than one candidate, pop up a child frame. Whereas preview always shows only the first candidate using overlay, and you must summon the popup with Tab if you want it. I guess as long as the overlay is visible, completion is "alive" and the table function is expected to keep track of input and update results.

[minad]

Well, I think we would always only show the topmost candidate (corfu-auto=preview). If you want to see more one would just use the current corfu-auto=t. What you're suggesting is a mix of both modes. Maybe there is also some value, but I doubt that, since it is rare that only a single candidate matches, and the result would just be an inconsistent UI where sometimes one thing and sometimes something else happens.